ThinkPHP二级域名缓存失效主因是runtime/cache目录权限错误及配置未按域名隔离；需检查并修复Web进程用户对cache目录的读写权限，同时使cache.prefix等配置动态适配HTTP_HOST，路由缓存也应按应用分离。
ThinkPHP 配置二级域名后缓存失效，多数情况并非缓存机制本身崩了，而是Runtime 目录权限错位 + 缓存路径/配置未按域名隔离共同导致的静默失败。Cache::get() 返回 null、日志不写入、模板编译失败、路由加载变慢——这些表象背后，往往只是 runtime/cache 对当前请求的域名所属 Web 进程不可写，或配置缓存把不同域名的设置混在了一起。
一、先确认是不是权限问题：Runtime/cache 是否真可写
ThinkPHP 不会报“权限错误”给你看，它只安静地跳过写操作。最直接验证方式是加一行代码：
// 在控制器或中间件里临时加
dump(is_writable(config('cache.stores.file.path')));
如果返回 false，就坐实了权限问题。此时别急着删缓存或清 route，先查三层：
- Web 进程用户是谁？运行
ps aux | grep -E '(nginx|apache|php-fpm)'，看 USER 列（常见：www-data、nginx、apache） - 缓存路径在哪？打开
config/cache.php，确认'path'值（默认runtime/cache，但可能被改过） - 该路径是否逐级可进入？执行
ls -ld runtime runtime/cache，重点看 runtime 目录是否有x权限（无 x 就进不去子目录）
二、Linux 下正确修复 runtime/cache 权限（两步缺一不可）
只改 chmod 或只改 chown 都不行。必须让 Web 用户既是所有者，又拥有合理权限位：
立即学习“PHP免费学习笔记（深入）”；
- 递归修改属主（把 www-data 换成你实际的 Web 用户）：
sudo chown -R www-data:www-data runtime/cache - 设置最小必要权限（目录 755，文件自动继承 644）：
sudo chmod -R 755 runtime/cache - 启用 setgid 确保新生成的 hash 子目录（如
a/ab/）自动继承组：chmod g+s runtime/cache
注意：不要用 777。线上环境暴露写权限等于敞开大门；Windows 用户请右键目录 → 安全 → 添加 IIS_IUSRS 或当前 PHP 用户 → 勾选“修改”和“写入”。
三、二级域名专属坑：配置缓存不能“一锅炖”
ThinkPHP 的 php think optimize:config 默认把所有 config/ 下的文件合并成一份缓存，但二级域名常需差异化配置（比如 api.example.com 用 Redis DB 1，admin.example.com 用 DB 2）。共用一份缓存会导致：
- 配置项被后加载的域名覆盖（如
cache.prefix被覆盖） - 数据库连接、日志路径等关键项冲突，引发异常
- 缓存写入看似成功，实则落到了错误实例或路径
解法是让配置“动态适配域名”：
在 config/app.php 中，把域名敏感配置写成运行时值，例如：
// cache_prefix 根据 Host 自动区分
'cache_prefix' => $_SERVER['HTTP_HOST'] . ':'
⚠️ 注意：此写法仅适用于 Web 请求环境；CLI 命令（如缓存生成）需配合 --env=production 或入口预设 Host，否则会报错。
四、顺手检查路由缓存是否也中招
二级域名启用后，若你还用了 Route::domain() 分组（如 Route::domain('api.example.com')->group(...)），默认的 php think route:cache 会生成一份全局缓存，但运行时仍要动态比对 $_SERVER['HTTP_HOST']——这步无法被缓存跳过，性能下降，且容易因 Host 解析不准导致匹配失败。
更稳妥的做法：
- 收敛为 path 前缀路由（如
/api/xxx），用中间件做分流或权限控制 - 若必须多域名多应用，开启多应用模式，并为每个应用单独生成路由缓存：
php think route:cache --app=apiphp think route:cache --app=admin
缓存文件将分别生成在runtime/route/api/route.php和runtime/route/admin/route.php
