静态优先:把复杂度挡在构建期之外

“要不要上一个后端?” 这是很多内容站点最初的岔路口。对于一个以阅读为核心的站点,我的答案是:先别。

什么是静态优先

静态优先(static-first)的意思是:把尽可能多的工作放到构建期完成,而不是留到用户访问时的运行期。文章在部署前就被渲染成最终的 HTML,服务器要做的只是把文件原样发出去。

这带来三个层面的好处。

一、速度

没有运行时计算,意味着没有”先查数据库再拼页面”的延迟。配合 CDN,用户拿到的是离他最近的一份缓存文件。

# 带 hash 的静态资源可以永久缓存
location /assets/ {
  add_header Cache-Control "public, max-age=31536000, immutable";
}

二、成本

静态文件几乎不消耗算力。一台最小的服务器,甚至一个对象存储桶,就能扛住可观的流量。

三、安全

这是最容易被低估的一点。没有服务端代码在运行,就没有 SQL 注入、没有 RCE、没有需要打补丁的运行时漏洞:

攻击面	动态站点	静态站点
数据库注入	有	无数据库
服务端代码执行	有	无可执行代码
依赖运行时漏洞	持续	仅构建期

你无法攻击一个不存在的后端。

那需要”写入”的时候怎么办

发布新文章确实是一次写入。但它可以被隔离成一个独立的、最小权限的服务:它只负责把 Markdown 净化、写文件、触发一次重建,然后就退回到只读状态。读和写,从此泾渭分明。

静态优先不是”功能上的妥协”,而是把复杂度挡在用户到达之前。当你真的需要动态能力时,再精准地加回来——而不是一开始就背上一整个后端。