Z-Blog 缓存三层：改了东西不生效该清哪一个

Z-Blog 的「改了没反应」几乎都能归到三层缓存里的某一层。三层各管各的，清错地方就是白清。先把它们分开看，再谈怎么清。

一、三层分别是什么

三层的更新时机完全不同，这是所有混乱的源头。

二、判断顺序：从外往里查

不要一上来就清缓存。按这个顺序查，能少走大半弯路：

1. 强制刷新浏览器（Ctrl+F5）先排除第 3 层
2. 看数据库里数据确实改了没——用后台编辑页或直接查表
3. 数据对、前台不对 → 是第 2 层
4. 数据不对 → 写入环节就错了，跟缓存无关

第 4 条最容易被误判成缓存问题。用 API 或插件写入时字段名传错（比如把摘要写进 Metas 而不是 log_Intro），前台当然不会变，怎么清缓存都没用。

三、模板缓存：必须手动重编译

改了主题目录下的 template/*.php，编译缓存不会自动更新。三个触发方式：

• 后台「清空缓存并重新编译模板」
• 主题切换一次再切回来（会重建）
• 删掉 zb_users/cache/compiled/主题名/ 整个目录

验证办法：看那个目录下对应 .php 文件的修改时间。如果改了模板后时间没变，说明压根没重编译——这时候你改的所有标签都还在旧版本里。

四、数据缓存：哪些操作会自动清

通过 Z-Blog 正规 API 写入（$article->Save()）时，系统会带上清缓存动作。但下面几种情况不会：

• 直接改数据库（SQL 或 table_update）——不会自动清
• 插件自己写文件做缓存——得插件自己负责失效
• 切换了主题但没重建模块——导航栏可能还是旧的

所以用 SQL 或工具改完数据，必须手动清一次。这是操作顺序问题，不是 bug。

五、模块是独立的一份缓存

侧栏模块、导航栏的内容不是实时读库的，是编译进缓存文件的。{module:navbar} 取的是 $modules['navbar']，这个数组来自缓存。

改完模块或调整侧栏顺序后，要单独「重建模块缓存」。很多「导航栏改了顺序没生效」都是漏了这一步。

六、清缓存该清到什么程度

「全清」的成本很低——就是重新生成一堆文件，几十毫秒的事。纠结该清哪层，不如直接全清再复现一次，能省下大量试错时间。

七、如果全清还是不对

那问题基本不在缓存。三个方向：

• 插件挂了 Filter_Plugin_Template_Compiling_End 把内容改回去了
• CDN 或反向代理缓存了旧页面（服务器本地对、公网不对）
• 模板里取的是别的字段，你以为改的地方根本没被读

最后一条最常见。判断方法：在模板里临时 var_dump 一下真正取到的值，比对着数据库猜快得多。

小结

三层缓存、三种失效时机。口诀：模板靠重编译，数据靠重写入，页面靠强刷。清完还不对，就别再清缓存了，去看代码里到底取了什么。