ThinkPHP 8.0 路由缓存导致修改无效?部署脚本自动清除缓存文件
ThinkPHP8.0路由缓存未清除会导致代码修改无效。部署需依次:清空旧缓存(phpthinkclear:route)、关闭APP_DEBUG并确保runtime/可写、重新生成缓存(phpthinkroute:cache--annotation)。确认缓存生效需检查响应头X-Runtime-Route-Cache字段及runtime/下的缓存文件。若未生
路由缓存没清,改再多代码也白搭
上线后修改了注解路由或 config/route.php 配置,访问接口却一直返回 404 或者匹配旧规则——这种问题在 ThinkPHP 8.0 项目里并不少见。很多人第一反应是代码没改对,反复检查路由定义,甚至重新部署一遍,结果依然无效。其实根因很简单:部署脚本执行时 runtime/route.php 没被清除或重建,新路由定义被缓存文件完全屏蔽了。哪怕你刚在服务器上保存了新代码,框架启动时加载的还是上周生成的 route.php。

确认当前是否真正在用缓存路由
怎么判断当前到底走没走缓存?很简单,在任意控制器方法中插入下面两行代码,然后访问对应接口:
dump(thinkApp::debug());
dump(is_file(RUNTIME_PATH . 'route.php'));
第一行输出 true 表示 APP_DEBUG=true,此时无论 route.php 是否存在,框架都会跳过缓存、重新解析全部路由定义;第二行输出 false 说明缓存文件根本没生成或被误删,缓存逻辑从源头就断了。
APP_DEBUG=true 时,路由缓存形同虚设。 即使你刚执行过 php think route:cache,只要 .env 或 config/app.php 中最终解析出 APP_DEBUG=true,缓存就不会参与匹配。
部署脚本中必须执行的三步清除链
想要彻底解决这个问题,部署脚本里需要串行执行以下三步,缺一不可:
- 清空旧缓存 →
php think clear:route - 确保 APP_DEBUG=false 且 runtime/ 可写 → 否则
route:cache命令静默失败 - 重新生成 →
php think route:cache --annotation(若使用注解路由)
其中第二步是硬性前提:检查 config/app.php 中 'app_debug' => false,不能只依赖 .env;同时确认 Web 进程用户(如 www-data)对 runtime/ 目录有写权限。Docker 环境要校验 UID 是否一致,否则 route.php 会创建为空文件或根本不存在。
规避手动删除风险的两种脚本写法
方法一:用内置命令清理(推荐用于生产环境)
在部署脚本末尾添加:
php think clear:route && php think route:cache --annotation
方法二:强制刷新并重建(适用于 CI/CD 流水线)
先执行 php think clear:route,再验证 runtime/route.php 是否真实删除:
if [ ! -f "runtime/route.php" ]; then php think route:cache --annotation;
else echo "route.php still exists, abort"; exit 1; fi
注意:不要用 rm -f runtime/route.php 替代 php think clear:route——前者可能残留索引文件或临时锁,后者会精准删除 runtime/cache/route.php 及所有关联临时文件,不依赖目录权限判断,也不受 IDE 隐藏文件干扰。
验证缓存是否真实生效
部署完成后,在项目根目录执行:
curl -I http://localhost/index.php?s=/api/test
观察响应头中 X-Runtime-Route-Cache 字段是否为 loaded;若无此字段,说明缓存未启用或加载失败。
再检查 runtime/route.php 文件内容是否为非空 PHP 数组,结构类似 return ['api/test' => ['api/test', 'GET', [], []]];。若内容是 return []; 或语法错误(如含 PHP 8.1 特性但 CLI 使用 PHP 8.0),缓存逻辑会在运行时自动 fallback 到源码解析,等于没开。


































