给论坛开了套金币体系，改了几处设置，前台就是不变化——改完刷新，跟没改一样。那阵子我一度怀疑是浏览器缓存，清了一遍又一遍。

后来才明白，Discuz 的设置缓存根本不是「一个缓存」，它其实存在三层：

  • 数据库 pre_common_syscache 表——这是真身，设置序列化后存在这里（ctype=1 那种）；
  • Redis 镜像——前端读设置，读的往往是 Redis 里那份；
  • filecache 文件缓存——另一份落盘的影子。

我一开始干的蠢事是：去删 Redis。删完一看，设置还是旧的。原因也简单——表里那份旧快照会把它回填回去。你删的只是三处中的一处，另外两处转眼就把旧值端回来，于是「改了跟没改一样」。

正解不是手动删哪一处，而是走 updatecache('setting') 把设置重建一遍，三处一次性对齐。重建完前台才真正变过来。

Discuz 设置的三层缓存：pre_common_syscache 表、Redis 镜像、filecache，以及正确刷新路径 updatecache('setting')

顺带还踩了个连带的坑，值得单独拎出来说：这个重建脚本，如果你不在站点根目录、而是在某个子目录里跑，它会照着当前路径把 siteurl 拼成「域名/子目录」。结果就是——全站图标和静态资源一起 404，首页像被拆了骨架。站没错，是脚本站在了错误的地方。

回头看，这条踩坑其实就两句话：

  • 缓存删了一处，另外两处会把旧值给你端回来——要清就整体重建（updatecache），别单点下手；
  • 会读写站点路径的脚本，站在哪个目录里跑，结果不一样，动手前先 cd 到站点根。

论坛这套金币体系，之前也写过一篇，讲规则怎么定、几笔账怎么算（那篇在这）。

这次排查的完整过程也发在了论坛：Discuz 改了设置就是不生效，缓存有三层。

做多站运维的，站点/缓存/路径这类「改了不生效」最费时间。平时用七亿批量远程管理工具把几台机器批量连上去看，能省掉来回登录；缓存这种却只能按层去对——这也是七亿批量远程管理工具帮不上、得靠人眼的一步。手边站点多的，官网那份安全科普里对面板和缓存维护也提了几句。说到底，七亿批量远程管理工具能帮你少登几次，判断「哪一层在骗你」，还得自己顺着 Redis、表、filecache 一层层看。