Project

为什么 static-only 很重要

解释 Jenna Press 为什么去掉 server 假设，转向纯静态发布模型。

静态交付是战略决策，不是技术上的权宜之计

大多数 CMS 项目起步时目标都很简单：发布内容，让需要的人找到。一年之内，站点悄悄长出了一个数据库、一个运行时层、一套部署流水线，还有一组没人记得完整的编辑规则。最初的意图是发布——最终得到的却是一个需要持续维护的轻量应用。

这不是团队的问题。这是结构性的漂移，原因是大多数框架在加入运行时行为这件事上极其容易，而让人察觉不到累积的重量，直到它已经摆在那里了。

依赖服务器的站点做了两件看似方便、实则有长期问题的事。

第一，它制造了运维依赖。内容存在于某个需要运行、监控和更新的地方。这个层一旦宕机，站点就宕机；这个层需要升级，站点就需要一个迁移窗口。团队现在拥有的是基础设施，而不仅仅是发布能力。

第二，它制造了一个隐性的维护面。一旦有了服务器，往里加表单处理、用户认证、评论系统、API 端点就成了很自然的事——一个接一个，每一步都没有清晰的决策节点。每一项新增都在缩小那个能放心地在站点上工作的团队规模。

传统的网站策略假设"留言板"是一个合理的获客渠道：访客看完网站，填个表单，有人跟进。这个假设早已不符合现代客户的到达路径。

今天，一个项目网站的 primary function 不是通过网站本身完成转化，而是让网站可被发现、可信，同时把关系转交到一个社交媒体渠道——LinkedIn 主页、GitHub 仓库、X 推文串——真正的互动发生在那里。

一个加载缓慢、需要运维服务器、把所有内容预算都花在"联系我们"表单上的网站，优化的是人们早已不再使用的那套工作流。而真正带来感兴趣的社交渠道，反而只在页脚塞了一个模板链接。

静态交付彻底消除了运维依赖。网站就是 CDN 上的文件。没有运行时要监控，没有服务器要打补丁，没有数据库要备份。发布的工作流就是：写 markdown，跑 build，部署。这就是整个运维面。

更重要的是，static 约束强制团队清晰化网站的实际用途。当加一个功能需要先问自己"这该放在静态构建里，还是该作为独立服务"，决策就变得显式了。那些无法静态工作的功能——实时聊天组件、实时推送——要么砍掉，要么交给外部服务并明确交接点。项目保持精简，因为框架不会让精简变成可选项。

静态交付不是通用答案。一个需要用户生成内容、实时协作或事务逻辑的网站，没法在不引入外部服务的前提下保持 static-only——而那些外部服务会把"约束"本想避免的复杂性重新带回来。

Jenna Press 不是反对那些场景，而是主张对它们保持诚实：如果项目真的不需要服务器层，就不应该仅仅因为"框架太容易加了"就背上一个。

Jenna Press 里的 static 边界是迫使这种诚实的机制。它让项目网站的边界始终可见，让团队的注意力放在那些把人引进来的内容上，而不是把人挡在外面的基础设施上。