在「万物动态」时代做静态优先

越来越多人倾向于在服务端动态渲染一切。Edge 来了之后，说法是动态渲染几乎免费：在 edge 跑个函数、毫秒级返回 HTML，用户无感。那还折腾静态生成干什么？

但物理规律还在。再快的 edge function 也快不过从 CDN 直接送出一份预编译的静态文件。静态文件已经在那儿，没有冷启动、没有函数调用、没有数据库往返。请求到 edge，字节就上线路了。这个基线很难被超越。

这个个人站我明确选了静态优先：站点在 build 时生成一次，你打开这页时没有数据库查询、没有服务端算 HTML，每条路由就是一个文件。部署也简单：把构建产物推到 CDN 就完事。没有要扩缩的运行时、没有生产环境要轮换的密钥、没有凌晨三点「function 超时」。

显而易见的反驳是：动态数据怎么办？博客可以全静态，但如果你想展示会变的东西——最近动态、实时计数、按用户的内容呢？

我想在首页展示最近 GitHub 贡献。有三种做法：在客户端 fetch——简单但慢、容易 loading 转圈；按请求在服务端 fetch——数据新鲜，但每次打开都变动态，静态的好处就没了；或者在构建过程里 fetch。构建时跑一个脚本，从 API 拉数据，写到 public/ 下的 JSON，前端当普通静态资源读。数据新鲜度等于上次部署。对贡献历史这类需求，够了。

这种混合——静态 HTML + 静态数据产物——既有「像动态」的观感，又有静态托管的稳定。页面加载快，数据已经在页上，没有 loading 状态、没有客户端 fetch 瀑布。JSON 差几小时对这类场景成本可以忽略。

不是每个项目都能或该全静态。需要登录的仪表盘、实时协作、真正个性化信息流需要服务端。但很多内容站、营销站、文档、个人首页不需要。行业偏向「先做动态再把它做快」，默认就成了服务端渲染 + 客户端 hydration，哪怕 build 时打一版快照就够。工具好用、默认说服力强，很容易顺手就选动态，而不问数据是否真的需要每次请求都实时。

所以纪律是：默认静态。只有在你有一个具体理由——用户身份、实时更新、或确实无法在 build 时得知的数据——时才加服务端或 edge function。有时候最好的架构决定是决定不用那件新的动态工具。CDN 早就是正确答案，你只需要让它干活。