静态站点生成器和内容系统混着用，哪些页面适合提前生成

静态站点生成器和企业内容系统混着用，哪些页面适合提前生成——判断线是这一页会不会被频繁改动、要不要认访客身份。生成器把内容在构建期编译成现成文件，读取时几乎不需要计算，官方页把它描述成以速度见长、用 Go 语言实现的静态站点生成器，整站在很短时间内就能重建；代价是每次改动都要重新构建与部署。内容系统把成本放在请求当下，换来随时可改、可按身份返回不同结果。两类工具各占一段，页面分工写清楚就能同时拿到两边的好处。

两类工具各自把成本放在哪一步

提前生成的那一路，成本集中在构建期：写入与审核完成后触发一次生成，读请求命中的是现成文件，服务器压力小，也少掉一层运行时依赖。动态内容系统那一路，成本分散在每次请求：取数据、套模板、判权限、写缓存，好处是改了就生效，不需要发布动作。读多写少的页面放在前一路更划算，写多读少的页面放在后一路更省事。

适合提前生成的页面类型

文档、手册与归档正文是典型的读多写少：编辑一次，被读上千次，提前生成能把读取成本压到很低。活动落地页同理，活动期间文案基本不动，页面数量与地址结构可控。

不适合静态化的页面特征

只要满足一条就别勉强：需要按登录身份返回不同内容；需要访客写入数据；内容随时间实时变化；同一地址要为多语言或多站点返回不同结果。评论、留言、表单提交、会员分组下的正文都落在这些条件里。硬把它们塞进生成流程，要么把写操作搬去第三方再回灌，要么在页面里塞脚本动态拼装，读取时省下的成本会以另一种形式加回来。

混着用时的地址与发布节奏

两套系统最容易出问题的是地址风格与发布时间。地址上，动态侧启用伪静态规则，把列表页与正文页的地址形态写成与生成侧一致的风格，同一栏目下的路径模板统一，避免出现同一内容有两种可读地址的情况。AnQiCMS 的伪静态规则支持自定义，能按栏目分别设定，把这一段对齐后即可放心把文档类内容交给生成侧。

发布节奏上，定时发布负责让内容按预设时间上线。混用时要区分两种触发：动态侧到点即生效，生成侧还要等一次构建完成。把每天固定的构建任务排在内容密集发布之后，或者让发布动作直接触发增量生成，两条时间线才不会错位。如果整站在很短时间内就能重建，排在发布之后风险不大；重建耗时长的项目，则更适合增量触发。

地址与节奏对齐后，还要保留一处统一的导航来源。让导航设置由动态侧维护，生成侧只读取同一份结构，栏目改名或新增时两边一起变，不靠人工同步。

常见问题

提前生成的页面怎么改错别字？ 走同一条发布链：在内容系统里改，触发重建，再核对生成结果。直接在生成文件上改会被下一次构建覆盖。

列表页能不能也提前生成？ 可以，但要看更新频率。高频新增内容会让构建频繁触发，收益被运维成本抵消；多数项目让列表页留在动态侧配缓存更划算。

多语言站点适合哪一侧？ 页面本身可以生成，但语言切换与整页翻译的管理留在内容系统里，由同一份结构驱动两边，避免译文与原文地址脱节。

混用会增加运维负担吗？ 会多一条发布链和一套地址约束。写清分工、把地址与发布时间对齐之后，额外负担主要落在构建监控，而不是日常编辑。