如果你只是偶尔写技术笔记，一台 1 核 1G 的云服务器每年也要一两百块，再加上备份、证书续期、MySQL 偶尔把内存吃满，养站的隐性成本并不低。纯静态站是这个问题最干脆的解法：内容在本地生成成一堆 HTML，托管在对象存储或免费的静态托管平台上，没有数据库、没有运行时、没有可以被撑爆的进程。这篇文章讲一个个人技术博客从动态站迁到纯静态的完整过程，包括生成器怎么选、评论和搜索这两个「必须有」的功能怎么补、以及迁移时最容易丢的东西。

一、先判断你该不该迁

静态站不是万能的，迁之前先把不适合的情形排掉，否则会白折腾一轮。

不适合的第一种：有会员、有后台投稿、有需要即时写入的功能。静态站没有后端，任何「用户提交后立刻出现在页面上」的需求都要额外接一个服务。第二种：内容量很小、更新极不频繁。三五篇文章，动态站反而更省事。第三种：已经有一套跑了很久、有稳定流量和收录的动态站，迁站本身的 SEO 风险大于省下来的成本。

适合的画像很清楚：以图文内容为主、更新节奏稳定、评论可以接受异步、对打开速度敏感、希望成本趋近于零。大多数个人技术博客都属于这一类——它们 99% 的请求只是在读，却为了那 1% 的可能写入养着一整套 PHP 和 MySQL。

还有一个常被忽略的收益：静态站的备份就是「复制一个目录」，迁移就是「换一个 bucket」。这件事的价值不在平时，在你需要救命的时候。

二、生成器选型：三种形态，三种代价

主流的静态生成器分成三种形态，选型的关键不是哪个更快，而是「你的内容以什么形态存在」。手头已经有一批 Markdown 就选直接吃 Markdown 的；内容是数据库导出的就选能接数据源的；打算用交互式笔记本写技术笔记的另有一条路。

第一类，文件即内容。Hugo 是这一类里构建最快的，一个几百篇的站通常在几百毫秒到两秒内构建完成，单文件二进制，不需要装运行时。它适合内容量大、要频繁全量重建的场景。缺点是模板语法学习曲线略陡，短代码和模板变量比别家更抽象。

第二类，生态即插件。Eleventy 和 Astro 这类基于 Node 的工具，优势是能复用前端的工具链：想用 Sass、想跑一段 JS 处理图片、想抽组件，都有现成的做法。代价是要维护 node_modules，两年后回来重建站点时，依赖版本可能已经装不上了。

第三类，生态成熟但重。Jekyll 是老牌方案，主题和插件最多，但构建慢、Ruby 环境在服务器上经常出问题。现在更适合当参考，不建议新站选它。

给个人站长的实际建议：内容以 Markdown 为主、追求稳定和省心，就选 Hugo；需要在页面里做较多前端交互、或者本来就熟悉打包工具，就选 Eleventy。两者都能做到「换台电脑一条命令就能重建」，这个要求比任何功能清单都重要。

三、目录结构与内容约定

静态站长期维护的关键在于目录约定，因为没有任何东西在后台帮你保持一致。一个够用的结构是这样的：

content/
  posts/2026/11/svg-icon-system.md
  pages/about.md
static/
  uploads/2026/11/xxx.webp
layouts/
  _default/single.html
  _default/list.html
config.toml

三条规则值得写进 README。第一，文章一律按「年/月/文件名」放，文件名用英文或拼音短横线连接，不用中文——这个路径会直接变成 URL。第二，图片统一放 static/uploads 下，用同一套年月目录，正文里引用绝对路径。第三，每篇文章的头部元数据固定四个字段：标题、日期、描述、分类，不要自由发挥。描述这个字段尤其重要，它会成为搜索结果里那段摘要，很多静态站因为没写描述而在搜索结果里显示成页面开头的一堆导航文字。

日期格式务必统一带上时区。静态站的时间不会有一个数据库默认值替你兜底，一个写成 2026-11-07、一个写成 2026/11/07 10:00，排序就会乱，而且不会报错，只是首页顺序莫名其妙。

四、把评论搬到静态站：两种取舍

评论是迁站时最大的心结。三条路，各有明确的代价。

方案一：第三方评论服务。Giscus 基于 GitHub Discussions，访客用 GitHub 账号登录评论，数据留在你自己的仓库里，没有广告也没有隐私争议。代价是国内的访客大多没有 GitHub 账号，实际评论量会明显偏低。Disqus 生态更广，但加载慢、带追踪，国内访问不稳定，个人站不太建议。

方案二：静态表单服务。用第三方表单服务接收留言，管理员审核后手工发布。好处是不需要数据库、没有噪音，坏处是「评论」变成了「留言」，不适合讨论型站点。个人技术博客其实够用，很多技术讨论最终都跑到邮件和 Issue 里去了。

方案三：自建轻量后端。只为一个评论功能养一台服务器，等于把省下来的成本又还回去了。除非你本来就有一台常年在跑的服务，否则不建议。

评论区的位置和加载方式也有讲究：用 loading="lazy" 的 iframe 或者点击后才加载，避免第三方脚本拖慢首屏。一个静态站的核心优势就是快，别在最后一步把它交出去。

五、站内搜索：无后端的三种做法

没有数据库也能搜索，思路都是「把索引变成静态文件」。

做法一：预生成一个全文索引文件。构建时输出一个 JSON，包含每篇文章的标题、链接、正文纯文本，页面上加载后用 JS 做模糊匹配。几百篇文章的索引压缩后通常在 200 KB 到 1 MB，对技术站完全可接受。

做法二：只索引标题和摘要。索引体积能压到几十 KB，代价是只能按标题命中。实际使用中，访客多半也是靠标题回忆的，这个折中很划算。

做法三：接外部搜索服务。把索引推到托管搜索服务，用它的 API 查询。功能最强，但引入了一个外部依赖和配额限制。

实现细节上有两件事必须做。一是索引文件本身要带缓存头，同时用一个随构建变化的名字（比如带内容哈希），这样更新内容后访客不会拿到旧索引。二是搜索结果页要能被搜索引擎正确处理：加 noindex，同时不要在 robots.txt 里 Disallow 这个路径——两者同时做会让搜索引擎看到「被禁止抓取但又在索引里」的矛盾状态，最终表现为搜索结果页长期以空描述出现在索引里。

六、部署：对象存储还是静态托管平台

两种主流托管方式，区别在谁管构建。

对象存储加 CDN。构建产物上传到对象存储的 bucket，前面套 CDN，源站就是那个 bucket。控制力最强，可以做精细的缓存规则、防盗链、图片处理，成本是所有方案里最低的——一个几 GB 的站，存储加流量的花费通常只有每月几分钱到一两块钱。代价是你要自己配证书、自己处理缓存刷新、自己保证上传是原子的。

静态托管平台。把仓库连上去，推送即构建部署，证书和 CDN 都不用管，很多平台免费额度就够个人站用。代价是构建环境不透明、构建时长有上限、以及平台策略变化时你没有议价能力（近年这类平台的免费政策调整过好几轮）。

个人站的稳妥组合：以仓库为唯一事实来源，主站放在对象存储上（长期可控），把托管平台作为一个「预览环境」用来检查每次构建是否正常。这样既有免运维的便利，又不把身家压在别人的免费策略上。

七、缓存与证书：静态站最容易配错的两处

静态站的缓存策略和动态站完全不同——因为内容不会变，可以放心地把 HTML 也缓存起来。但前提是「每次发布都换了文件名或者刷新了缓存」。

推荐策略：/uploads/ 下的图片、CSS、JS 带内容哈希的文件，缓存一年并标 immutable；HTML 文件缓存较短（比如十分钟），并依赖发布时主动刷新。判断失误的典型症状是：文章改了一个错字，访客刷新十几次还是旧内容，而自己在手机上看到的是新的——因为手机没走缓存。

证书方面，静态站通常只需要一张给主域名和裸域的证书。如果平台自动签发就不用管，用对象存储加 CDN 的则要确认续期任务在跑，并且续期成功后 CDN 真的用上了新证书。验收方法不是看配置文件，而是看线上握手拿到的证书到期时间：

echo | openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -dates

这条命令打出来的 notAfter 才是访客实际会看到的那张证书。它和服务器上的文件对不上，说明中间有 CDN 或者负载均衡在用自己的证书。

八、从动态站迁移：最容易丢的五样东西

迁移的执行步骤各家不同，但踩的坑高度一致。

第一，URL 变了。这是影响最大的一项。原来的文章地址是数字 ID 加 .html，静态化之后往往变成日期加 slug。所有旧链接都会 404，外链和搜索结果里的入口全部失效。做法是保留旧路径作为 slug，或者生成完整的重定向表。重定向表要逐条校验，不能只抽查几条。

第二，图片丢了。动态站的图片常放在 usr/uploads 之类目录，正文里是相对路径。复制内容时如果只复制了 Markdown 没复制图片，页面上就是一排破图，而自动检查不会报错。做法是把上传目录整体搬到 static 下，并统一正文里的图片前缀。

第三，内链失效。正文里指向其他文章的链接常是动态地址。迁移后这些链接要一次性替换成新地址，否则站内会形成大量死链，对收录的伤害比外链死链更大。

第四，sitemap 和 feeds 没重建。静态站的 sitemap 是构建时生成的，如果模板没配好，它可能只包含最近几十篇，或者 lastmod 全是构建时间。后者的后果是每次构建都给搜索引擎发一遍「全站都更新了」的信号，多次之后这个信号会被忽略。

第五，统计和验证代码丢了。分析代码、搜索平台的验证文件、站长工具的所有权校验，这些通常放在模板里。模板一换，它们全部消失，而且是静默的——没有报错，只是数据不来了。

九、上线验收清单

静态站没有后台可以点，验收只能靠命令行，这反而更容易做成固定流程。建议每次发布后跑一遍：

• 首页和随机三篇文章返回 200，且页面里能看到正文的第二个小标题。
• 旧的动态地址随机抽五条，确认 301 到新地址而不是 404。
• 页面里所有 <img> 的地址逐个请求，状态码必须是 200——这一步能抓出全部破图。
• sitemap 能打开，条目数与文章数对得上。
• 证书到期时间大于 21 天。
• 搜索页返回 noindex，且 robots.txt 里没有 Disallow 它。

把这几步写成脚本挂在每次部署之后，几分钟就能跑完，比事后去搜索平台看「为什么收录掉了」便宜得多。

十、小结

纯静态不是「更先进」，而是「把不该常驻的东西去掉」。它的代价很明确：失去了任何即时写入的能力，评论和搜索要靠额外方案补；它的收益也很明确：没有运行时就没有可以被撑爆的进程，备份是一个目录，迁移是换一个 bucket，成本趋近于零。判断一个个人站是否该走这条路，只需回答一个问题：你的访客中有多少比例是在写入。如果答案是百分之一以下，那么为那百分之一养一整套后端，性价比就已经很低了。真正需要谨慎的是迁移本身——URL、图片、内链这三件事要在上线前逐条验证，因为它们是唯一会让「省下来的成本」变成「丢掉的流量」的地方。