cache_prefix仅在File驱动且path_level=0时生效；Redis等驱动需配置stores.redis.prefix，多应用须手动设前缀防冲突，启用path_level>0会跳过cache_prefix。
ThinkPHP 6 的 cache_prefix 配置在哪生效？
它只在使用 think\cache\driver\File（文件缓存）且未启用子目录分片（path_level = 0）时起作用；Redis、Memcached 等驱动完全忽略该配置，它们靠 prefix 或 serialize 机制控制命名空间。
实操建议：
-
cache_prefix是cache.php配置文件里的顶层键，不是驱动内部的参数，别塞进stores.file里 - 若用 Redis，必须改
stores.redis.prefix，例如设为'app1:'，否则所有应用共享 key - 文件缓存下，
cache_prefix会拼在生成的文件名前，如app1:think:config:database→ 实际写入app1_think_config_database.php
多应用如何避免缓存 key 冲突？
ThinkPHP 6 默认不自动隔离多应用缓存，app.name 不会自动注入到缓存 key 中 —— 这是常见踩坑点。你得手动干预。
推荐做法：
立即学习“PHP免费学习笔记（深入）”；
- 在每个应用的
config/cache.php中显式设置'prefix' => 'app_name:'（Redis/Memcached）或'cache_prefix' => 'app_name_'（File） - 不要依赖全局
cache.php，多应用项目应让各应用维护自己的缓存配置文件 - 如果用了
think-swoole，注意 Swoole Worker 进程间共享 Redis 连接，prefix必须在连接初始化时就固定，不能运行时动态改
为什么改了 cache_prefix 文件缓存还是混在一起？
大概率因为启用了 path_level > 0（默认是 2），此时 ThinkPHP 把 key 哈希后拆成子目录存储，cache_prefix 被跳过，不再参与文件名生成。
验证和修复：
- 检查
config/cache.php中'path_level'是否为0；设为0后，cache_prefix才生效 - 清空
runtime/cache/目录再试，旧缓存文件不会自动重命名 - 临时加日志：在
think\cache\driver\File::getCacheKey()里 dump 返回值，确认拼接逻辑是否符合预期
自定义缓存前缀影响哪些底层行为？
它不改变缓存生命周期或序列化方式，但直接影响 key 可读性、调试难度和跨应用清理成本。
关键细节：
- 前缀含非法字符（如
/、..、空格）会导致文件缓存写入失败，Redis 则可能触发协议错误，务必用字母+数字+下划线+冒号 - 前缀过长（>32 字符）在 Redis Cluster 下可能引发 slot 计算偏差，建议控制在 16 字以内
- 切换前缀后，旧缓存不会自动失效，需人工
flushdb或按前缀 scan + del，线上环境务必评估影响范围
最易被忽略的是：Swoole 模式下，修改配置后必须 reload worker，仅重启 HTTP 服务不生效；而 File 缓存的 cache_prefix 在 CLI 和 HTTP 请求中表现一致，但 Redis 的 prefix 在命令行任务里容易漏配。
