这套站点是怎么搭的

一句结论：一台机器、nginx 加 Let's Encrypt，所有页面都是磁盘上的静态文件；没有一个字节来自别人的服务器。

下面是我当时的取舍。写下来是因为过几个月我自己也会忘，而忘了之后做的决定通常更差。

为什么不用现成的博客系统

一开始想的是装个带后台的博客程序。后来发现我需要的功能其实只有两个：写文章、 按日期列出来。而一个动态程序为了这两个功能，要我额外维护数据库、依赖升级、 以及「某个插件停止维护了」这类问题。

静态页面的代价是加一篇文章要改两处（正文文件、列表里加一行）。我认了这个代价—— 文章不是一个高频操作。

为什么不引外部资源

这是最先定下的一条：不引字体、不引 CDN、不引统计脚本。页面上每一个字节都从这台机器出去。

原因很实际。看这个站的多数人在国内，而公共 CDN 的节点大多在外面，一次跨境请求的等待经常比 整个页面的体积还重要。字体尤其不划算：一个中文字体动辄好几 MB，而我用系统自带的宋体就够了。

顺带的好处是，页面不会因为别人的服务出问题而变慢或者变样。这条我也用在了别处—— 下面那个验证服务的服务端只用标准库，同一个道理。

证书与反向代理

nginx 配好站点之后，证书交给 certbot 自动签、自动续。配置里我不写 listen 那一行， 让它自己追加——包括 80 端口到 443 的跳转。

sudo certbot --nginx -d 域名 --non-interactive --agree-tos --redirect

好处是这几条命令可重复执行；坏处是配置文件从此是「生成的」，我手里那份只是输入。 真的要重建站点，顺序必须是：先铺站点配置，再跑 certbot。反过来会把 TLS 那一段覆盖掉。

顺带一提，这台机器上还有第二个域名指向同一个静态目录。那不是内容重复，是入口重复—— 我更想让人记住短的那个名字。

验证服务是另一套东西

同一个团队还维护一个授权验证服务，它和这个站不一样：那个是有状态的、要判断的、要留记录的， 所以它是自己写的，跑在回环地址上，由 nginx 转发出去。

两者唯一的共同点是那条「零第三方依赖」的原则。服务端只用标准库，代价是有几件事得自己写； 换来的是没有依赖供应链，也没有「某个库过期了」这种到期问题。

现在这样有什么不好

说缺点：加文章要手动改两处；没有评论、没有搜索；文章多了以后列表会长得难看。 这些都是我知道并且暂时接受的——真到了需要的时候再加，而不是现在就为它背上一个后台。

就先写到这里。