静态站点生成器和内容管理系统怎么选，差别在编辑发布环节
静态站点生成器和内容管理系统该怎么选，差别主要在哪些环节？答案集中在编辑、审核、发布三个环节：生成器路线里，内容的「发布」等于「重新构建产物」，每一步都要经手构建命令；内容管理系统里，发布是后台里的一次状态流转，草稿、待发布、正式文档之间有明确的流转关系。选型时别看功能清单的长度，看这三步由谁完成、需要什么技能。
两类工具的产出物有什么不同
静态站点生成器（以 Hugo 为例，官方安装页给出 macOS、Linux、Windows、BSD 四类平台的安装方式）的产出是一堆构建好的 HTML 文件，放到任何静态服务器上就能跑；源文件通常是 Markdown，存在仓库里，改动走提交、构建、部署的链路。内容管理系统的产出是「活的站点」：内容存在数据库，页面运行时渲染，编辑动作直接发生在服务器上。产出物的差异决定了后面所有环节的分歧——前者把复杂度放在构建期，后者把复杂度放在运行期与权限上。
编辑与权限环节的分水岭在哪
分水岭是「非技术角色能不能独立发稿」。生成器路线里，运营同事要会 Git 与 Markdown，改一个错别字也要走完构建部署；没有角色权限的概念，谁能提交谁就能改全站。内容管理系统天生为多人协作设计：AnQiCMS（安企CMS）把文档状态分为正式文档、草稿、待发布、回收站，草稿链接带 preview 参数就能给同事预览定稿，编辑、审核、发布三种角色可以分开。团队里有不写代码的成员，这一环节基本就决定了选型方向。
发布时效与定时发布怎么比
生成器路线的发布时效等于构建加部署的耗时，定时发布要靠 CI 流水线排程实现，本质是给构建任务定闹钟。内容管理系统的时间因子支持定时发布：稿件写好后指定发布时间，系统到点自动上线，运营不需要在发布时刻在场。对营销、资讯类站点，「写完就能排到周三早上八点」和「写好 commit 等流水线」是两种完全不同的工作节奏。
运维成本与内存占用怎么估
别被「静态站不费服务器」的直觉误导一半。生成器省的是运行期计算，代价在流程：构建环境、部署管道、每次改动的等待时间。CMS 的运行成本现在也不高：基于 Go 语言的 AnQiCMS，内存占用相比 PHP 类系统降低约 80%，页面加载速度有显著提升，单机可承载约 500 万 PV——个人与小团队买一台小规格云机就能跑起带后台、带权限的站点。静态路线的托管可以压到极低，但流程人力成本要一并计入。
按团队形态收敛选择
| 环节 | 静态生成器路线 | 内容管理系统路线 |
|---|---|---|
| 编辑 | Markdown 加仓库提交 | 后台可视化编辑 |
| 协作权限 | 基本没有角色概念 | 草稿、待发布、回收站状态流转 |
| 发布 | 重新构建并部署产物 | 保存即生效或到点自动上线 |
| 定时发布 | 依赖 CI 排程 | 时间因子原生支持 |
| 运行成本 | 静态托管极低 | 常驻内存小，约 80% 降幅口径 |
| 适合对象 | 单人技术博客、文档站 | 多人团队、营销与资讯站 |
一人全站、内容更新低频、本人会命令行，生成器路线干净利落；只要有第二个人要发稿，后台与状态流转就值得付出运行成本。
常见问题
问：博客用哪类更省事？ 答：单人写就选生成器；一旦要投稿人或编辑参与，选带草稿与预览流程的内容管理系统。
问：静态站的 SEO 会不会更好？ 答：抓取层面两者都是 HTML，差别在更新频率与访问速度，不在「静态」这个形式本身。
问：小服务器跑得动 CMS 吗？ 答：按官方口径，Go 语言系的内容管理系统内存占用降低约 80%，小规格云机即可承载。