1. 最常见的原因：模板视图被缓存了

为了性能，模板解析结果会被缓存。启动时视图缓存的开关由配置项 view_reload 决定：

view_reload: false   # 默认：启用模板缓存，性能好
view_reload: true    # 关闭模板缓存，改完立即生效，性能差

所以直接在服务器上改磁盘上的模板文件，前台可能完全没反应——不是你改错了，是进程还在用缓存里的旧模板。

2. 三种改法，行为不一样

后台在线编辑之所以能立刻看到效果，是因为保存、重命名、删除等模板操作都会调用同一个「临时禁用缓存」逻辑，窗口是固定的 30 秒。这意味着：

• 改完要在 30 秒内刷新页面确认，超过窗口可能又读回缓存。
• 连续多次保存，窗口会重新计时，不用担心。
• 它是全局的，不是只针对你改的那一个文件。

推荐做法：开发调试期开 view_reload，上线后关掉。长期开着会让每次请求都重新解析模板，白白消耗 CPU。

3. 排查顺序

按这个顺序一层层排除，不要一上来就重启：

1. 确认改的是当前启用主题。系统用的是 ThemeRootDir() 解析出的当前主题，改了别的主题目录当然没用。
2. 强制刷新浏览器（Ctrl/Cmd + Shift + R）。静态资源被浏览器缓存是最常见的「假不生效」。
3. 确认改的文件被模板真正引用。如果改的是一个没有被 include 的片段，页面不会有任何变化。
4. 检查是不是内容缓存。内容发布后前台缓存会失效，但如果数据是从缓存读的，改模板能生效、改数据不生效——这个区别可以帮你定位。
5. 检查 CDN / 反向代理缓存。前面挂了 CDN 的话，源站变了边缘节点可能还是旧的，需要刷新缓存。
6. 最后再重启服务。重启能清空进程内的视图缓存。

4. 开发期的一个额外好处

打开 view_reload 后，模板渲染出错时页面会显示详细的错误信息，而不是只给一个 500。改模板时强烈建议开着，能省掉大量翻日志的时间。上线前记得关掉。

5. 生产环境改模板的正确姿势

1. 先在预发或本地验证，确认模板语法没问题（语法错误会让整页渲染失败，不是局部不生效）。
2. 优先用后台在线编辑，它会自动处理缓存失效。
3. 改完立刻访问受影响的每一类页面：首页、栏目页、详情页、单页——模板往往是共用的，但数据分支不同。
4. 看日志里有没有模板渲染错误。渲染失败通常只在日志里体现，页面上可能表现为空白或残缺。

6. 一个容易混淆的点

「改模板不生效」和「改内容不生效」是两回事：

• 改模板不生效 → 视图缓存（本节内容）。
• 改内容不生效 → 内容缓存或内容状态。先确认内容状态是已发布、栏目是启用的、栏目模板没有写死过滤条件。

先分清是哪种，能省掉一半排查时间。