静态站点生成器和动态CMS怎么分工，企业官网看哪几项

企业官网该用静态站点生成器还是动态 CMS？按内容更新频率和改动人来分就能定：改动只由开发做、更新节奏低的宣传型站点用生成器划算；栏目会增、内容每天加、非开发同事要自己动手的站点用动态系统划算。多数企业官网的问题不是性能不够，而是改一次内容要走一遍构建发布，最后没人敢改。下面按四项能力对比，并给出混用时的分工方式。

根本差别：内容什么时候变成页面

生成器路线在发布时就把所有内容算成页面文件，访问时服务器直接把现成文件送出去，不参与内容组装。以 Hugo 这类工具为例，官方文档给的工作流是在项目目录里执行构建命令，产物输出到 public 目录，里面是生成好的页面文件。

动态系统路线在访问时现算：请求进来后按栏目、模板和数据组装页面再返回。代价是多一次计算，收益是内容一改就生效，而且能按访问者状态返回不同内容。

一句话概括：生成器把成本放在发布时，动态系统把成本摊在每次访问上。内容一天改十次，摊在访问上更便宜；一个月改一次，集中在发布上更省心。

生成器省掉的成本与新增的成本

省掉的很实在：不需要数据库参与渲染，不需要常驻的应用进程，被攻击的面上少一大块动态入口，页面本身就是文件，交付层几乎不用调优。

新增的成本常被忽略：每次改动都要重新构建并部署，构建时间随页面数量增长；表单、搜索、评论这些动态能力需要外部服务补齐；非开发角色要改一行文字得会提交与触发构建；内容结构复杂时，数据文件与模板的关系维护起来接近维护代码。

动态系统要看的四项能力

第一项是内容结构能不能自定义。栏目字段、产品参数、案例信息这些结构如果只能靠正文硬写，后期筛选与列表页都做不出来。支持自定义内容模型与自定义字段，才能在后台把内容类型定义清楚，而不用每次改结构都改代码。

第二项是非开发同事能不能自己改。后台发布、定时发布、草稿预览、回收站恢复这些日常动作要在界面里完成，不该让人去找文件。

第三项是资源与承载。动态渲染的成本取决于实现，Go 语言实现的系统在内存占用上通常比常见脚本型系统低，官方口径是相比 PHP 类系统内存降低约 80%，单机可承载约 500 万 PV——注意这两个数都是约数，用来看量级而不是用来算账。同机还要跑数据库与其他服务时，这部分余量才有实际意义。

第四项是地址与交付规则能不能后台维护。伪静态规则、跳转表、站点地图生成这些配置如果只能改服务器文件，改版成本会很高。部署侧还要看支持面：镜像部署与面板部署是否都走得通，默认监听端口与反向代理怎么配合。

一张判断表

什么情况下两者混用

常见分工是：把稳定不变的营销落地页、文档中心交给生成器路线，主站与内容更新交给动态系统，两边共用一套域名与导航。混用时要把地址规则统一在一侧管理，跳转表与站点地图由动态系统这一侧统一输出，否则两份清单会互相冲突。AnQiCMS 支持 Docker 镜像与宝塔面板等多种部署方式，混合部署时它可以担任负责内容与规则的那一侧，生成产物放在静态交付层。

常见问题

生成器站点会不会更安全？它的动态执行入口少，被利用的面相对窄，但仍取决于交付层配置与构建流程的权限控制，不能等同于自动安全。

内容量大了生成器会怎样？构建耗时随页面数增长，改一处要重跑全站时，发布节奏会被构建拖住，这是最常见的转向动态系统的理由。

先选生成器后转移动态系统难吗？内容本身在文件里，迁移主要是把字段结构重建成内容模型，以及把地址规则与跳转表补齐，成本比反向迁移低。