正篇五篇把正经 CMS 过完了，番外一聊过静态站生成器，番外二收了论坛和 Wiki。这篇接番外一补边界：它给了"想要快而静的站"三条路——扁平文件 CMS（Grav 那批）、WordPress 静态化、换语言上真 SSG——可这三条路各自有软肋，跨过某条线就翻车。翻车的典型症状不是"站坏了"，是"站做出来了，内容却根本没法正常维护"——这种坑最隐蔽。
一、静态方案的五个软肋
1. 编辑后台顶多是个"半成品"。 扁平文件 CMS（Grav 那批）是带了编辑界面，可那是单人在用的简易后台——没有角色、没有审批、没有草稿流，编辑一多照样乱；纯静态（SSG、导出的静态站）干脆没后台，改一个字都要走 Git，要求每个编辑会改文件；WordPress 静态化倒是留了完整后台，但那等于还在养整套 WordPress，只省个服务器钱。团队里好几个不写代码的人要天天发内容？第一件事就别往静态方案想。
2. 权限和审批基本靠自觉。 CMS 里的角色（管理员、编辑、审稿人）、草稿、定时发布，静态方案统统没有。内容要多人协作、要留审批痕迹的，直接出局。
3. 动态功能全要外挂。 评论、搜索、表单、用户登录、价格实时变动——静态页面一个都做不了，全得靠第三方服务（评论挂 Disqus/giscus、搜索接 Algolia/Pagefind）或回到动态后端。外挂越多，你当初选静态图的那份"简单"就越是假的。
4. 内容一多，构建就慢，发布就不"即时"。 上千篇文章之后，改一个错别字也要把全站重新构建一遍（WordPress 静态化插件更是要把整站爬一遍），构建从秒级涨到分钟级。于是发布变成有延迟的动作：编辑白天改完，构建晚上失败，第二天线上还是旧稿——个人博客能等，内容型大站天天这么等，受得了吗？
5. 站点逻辑是"代码"，改动走开发。 换主题、加栏目、调结构，全是改代码重构建的事——等于网站永远处于开发状态，没有"运营"这回事。这是静态方案最反直觉的一点：它把发布变成工程，把运营者变成开发者。
二、翻车前的那条线在哪
先看两种典型的翻车姿势。一种是 WordPress 上了静态化，编辑照常在后台写，但发布要靠手动触发导出——改完忘了点，线上半个月没动静，还没人发现，因为"静态站很稳定，不会出问题"；另一种是几个人一起用 Markdown 维护，改完没拉最新就提交，互相覆盖，Git 冲突解到吐。两种都不是"站坏了"，是没人说得清线上现在是什么内容——静态方案的稳定是优点，却也最容易掩盖"发布链条已经断掉"这件事。
对照一下就知道：静态方案适合"内容增长慢、编辑人少、站型固定"的站（个人博客、团队文档、小型官网、作品集）；一旦内容要天天更新、编辑不止你一个人、或者站要跟着业务变，就该回真 CMS。
具体场景，直接抄：
个人博客 / 作品集，自己写自己发，内容一周一篇——扁平文件 CMS（Grav）或 Typecho，图省心；
已经用 WordPress、线上访问量上来了想省服务器钱——WordPress 静态化（保留后台编辑）；
团队文档站、要多人协作维护——别静态化，直接 DokuWiki（番外二盘点过的轻量 Wiki，无数据库那种）或正篇的 CMS；
企业官网，编辑是市场部的人，天天要改内容、要发布审核——WordPress 或迅睿（正篇 04 推荐）；
电商站、会员站、任何有登录和动态数据的——别碰静态方案，OpenCart 或正篇电商清单；
几十人内容团队、多层审批、要草稿要排期——静态方案全部出局，Drupal 或 WordPress 企业级玩法。
三、一句话收口
换个角度看，PHP 生态里"轻"的代价很特别：真 SSG 那条路（Hugo、Astro）是换语言重写，账在番外一算过；不换语言、留在 PHP 里的"轻"，代价基本就是砍掉后台。砍后台之前先问一句：这些内容到底谁在发、多久发一次、发完要不要审？ 三个问题答完，该选哪个基本就清楚了——多数人答完会发现，自己需要的不是更轻的方案，是正篇里那个被嫌重的 WordPress。
已经在静态方案里翻车了？内容都还在文件里，往回迁比想象中轻——但别以为"导出再导入就完事"，链接、图片、收录要跟着走，这套坑番外八讲系统迁移时拆过，思路通用。
一句话：静态方案图的是省心和速度，代价是把"运营"变成"开发"；只要内容需要多人、高频、有流程地维护，就回正篇清单选真 CMS，别在轻量化上硬撑。
本篇数据来源：内容以正篇五篇（WordPress / 迅睿 / Drupal / Grav / OpenCart 等系统的状态与推荐）为基础，本篇为取舍讨论，不再重复列系统数据来源。