静态站的好处是简单：没有数据库、没有服务器、没有运维。坏处是，很多原本由框架替你处理的细节，现在要你自己面对。
坑一：首屏等字体
一开始用了在线字体服务，页面结构一秒就好了，字却要等两三秒才换成正确的字形，中间那一下重排很难看。在国内网络环境下，这个等待经常直接变成失败，然后退回系统默认字体。
解决办法是把字体栈写成本地优先：中文用系统自带的黑体，标题用系统宋体，英文退回 Georgia。看起来朴素，但首屏立刻可见，而且零请求。
--sans: -apple-system, "PingFang SC", "Microsoft YaHei", sans-serif;
--serif: "Songti SC", "Source Han Serif SC", Georgia, serif;坑二：相对路径
文章放在子目录里，首页在根目录，两边的链接前缀不一样。第一次上线，所有文章页的样式表都 404，页面变成光秃秃的 HTML。预览时看不出来，因为本地浏览器缓存了旧路径。
现在我的做法是生成页面时统一传一个“根前缀”参数：根目录页面传空字符串，子目录页面传 ../，所有链接都拼这个前缀。这条规则简单到不会记错。
坑三：改了文件，看到的还是旧的
静态资源被 CDN 缓存是好事，但你在改样式时会很痛苦：明明保存了，刷新还是旧颜色，于是开始怀疑自己改错了文件。我在这上面浪费的时间，比写样式本身还多。
两个习惯能省掉这些时间：改样式时在地址后面加个随机参数强制刷新；上线后再改，就顺手把样式文件名里的版本号加一。
现在这套方案
- 纯 HTML + 一个样式文件，没有前端框架，也没有构建步骤；
- 页面由一个几十行的脚本从同一个模板生成，保证导航、页脚、样式永远一致；
- 托管在对象存储加 CDN，推上去就是一串静态文件，出问题只可能出在文件本身。
这套东西最大的价值不是性能，是可预测：出问题时，原因一定在你看得见的那几个文件里。