缓存前缀在 config/cache.php 文件的 'prefix' 配置项中设置，需统一修改所有环境配置、确保多级缓存驱动共用同一前缀，并配合清缓存、重启PHP-FPM等操作生效。
缓存前缀在哪配：cache.php 里的 prefix 配置项
ThinkPHP 默认用 think: 作缓存键前缀，所有项目共用这个前缀时，Redis 或 Memcached 里就会互相覆盖。改法很简单：打开 config/cache.php，找到 'prefix' => 'think:' 这一行，改成带项目标识的字符串即可。
常见错误是只改了开发环境配置，漏掉生产环境的 config/cache.php（尤其部署后走的是 config/production/cache.php）。另外，如果用了多级缓存（比如先查 File 再查 Redis），要确保所有驱动都共享同一套 prefix，否则行为不一致。
- 推荐用小写字母 + 下划线命名，比如
'prefix' => 'myapp_v2:' - 避免含特殊字符或空格，Redis 键名不支持，会静默截断或报错
- 如果项目已上线且缓存量大，改前缀后旧缓存不会自动清理，得手动 flush 或等过期
为什么不能只靠 cache() 第二个参数动态加前缀
有人试过在调用 cache('key', $val) 时，手动拼接项目名，比如 cache('myapp_v2:key', $val) —— 这看似能绕过配置，但实际埋了坑。
问题在于 ThinkPHP 的标签缓存（TagCache）、路由缓存、模板编译缓存等底层功能，全依赖全局 prefix 构建键名。你手动拼的只是业务层缓存，其他系统缓存仍用默认前缀，结果就是路由失效、模板重编译、标签失效全来一遍。
立即学习“PHP免费学习笔记（深入）”；
- 动态拼接只适用于明确由你控制的业务缓存场景
- 一旦开启
route_cache或template_cache，就必须统一走配置项prefix - 验证方法：清空缓存后访问任意页面，看 Redis 里是否出现大量
think:route:、think:tpl:开头的键
多个 ThinkPHP 项目共用 Redis 时的兼容性要点
同一台 Redis 实例跑多个 TP 项目，光改 prefix 不够，还得确认序列化方式和过期策略是否一致，否则会出现「A 项目写入、B 项目读出乱码」或「缓存永远不命中」。
ThinkPHP 6.0+ 默认用 serialize 序列化，但如果你在某个项目里显式设了 'serialize' => 'json'，而另一个没设，它们对同一键的读写就会互不识别。
- 检查每个项目的
cache.php中'serialize'值是否完全一致（推荐统一用'serialize' => 'php'） -
'expire'可以不同，不影响键冲突，但建议统一设为0（永不过期）或按需设置，避免某项目缓存意外提前淘汰 - Redis 数据库编号（
database）比前缀更彻底，但需要运维配合分配，不是所有环境都允许
改完前缀后必须做的三件事
改完 prefix 不等于万事大吉，TP 的缓存机制有延迟生效点，漏掉任何一项都可能让新前缀“看起来没生效”。
- 删掉
runtime/cache/目录下的所有文件（File 驱动残留会影响首次加载逻辑） - 执行
php think clear:cache，它会清空系统级缓存（包括命令行缓存、配置合并缓存） - 如果是 FPM 模式，重启 PHP-FPM 进程（OPcache 缓存了部分配置类，不重启可能还在用旧
prefix）
最容易被忽略的是第三点：改完配置、清了缓存、接口返回还是旧数据——大概率是 OPcache 没刷新，而不是前缀没生效。
