APP_DEBUG=true时php think clear:route不生效，因框架跳过路由缓存；生产环境须硬编码'app_debug'=>false、确保runtime可写，并按TP版本执行对应清理与重建命令。
php think clear:route 命令不生效？先确认 APP_DEBUG 状态
执行 php think clear:route 后路由还是旧的，大概率是因为 APP_DEBUG=true。只要最终解析出 debug 为 true（无论来自 .env 还是 config/app.php），框架就完全跳过 runtime/cache/route.php，每次请求都重新解析全部路由——缓存文件存在也等于没用。
验证方法：在任意控制器里加两行：
dump(\think\App::debug());<br>dump(is_file(RUNTIME_PATH . 'cache/route.php'));
第一行输出 true，说明缓存逻辑根本没启用；第二行输出 false，说明缓存文件压根没生成或被删了但没重建。
-
APP_DEBUG=true时，删route.php或跑clear:route都没意义 - 生产环境必须确保
'app_debug' => false在config/app.php中硬编码生效，不能只靠.env - Docker 或 Nginx+PHP-FPM 环境下，还要检查 Web 进程用户（如
www-data）对runtime/有写权限，否则route:cache会静默失败
TP5 / TP6 / TP8 清理方式完全不同，别混用命令
ThinkPHP 各版本对路由缓存的处理差异很大，用错命令等于白干：
Skill Weave Chains — 技能链路由引擎
下载
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
立即学习“PHP免费学习笔记（深入）”；
- TP5 没有
clear:route命令，必须手动删runtime/route.php（注意不是runtime/cache/route.php） - TP6 开始支持
php think clear:route，它删的是runtime/cache/route.php - TP8.0 默认路径变成
runtime/cache/route.php，但注解路由必须加--annotation才能识别@Route注解 - 若项目启用了多应用（如
app/admin），每个应用的runtime/cache/route.php都得单独清理或重建
删文件比跑命令更危险？不，是删错地方才危险
很多人怕手动删文件出问题，结果反而因依赖 php think clear 默认行为漏掉关键项——它默认不碰 route.php 和 view/ 目录。
-
php think clear只清runtime/cache/、log/、session/、trace/，不删route.php，也不清模板编译文件 - TP5 必须手动
rm -f runtime/route.php；TP6/8 推荐用php think clear:route，它会连带清理关联临时文件，比rm更安全 - 严禁
rm -rf runtime/：会删掉log/目录本身（导致后续日志写入失败）、session/（中断用户会话）、data/config.php（配置缓存丢失） - Redis 作缓存驱动时，
route.php文件删了也不够，还得进 Redis CLI 执行DEL think_route:*类 key
部署脚本里漏掉这三步，缓存永远清不干净
CI/CD 流水线或上线脚本中，仅执行 php think clear 是典型错误。必须串行完成：
- 第一步：
php think clear:route（TP6+）或rm -f runtime/route.php（TP5） - 第二步：确认
APP_DEBUG=false且runtime/可写（可用ls -l runtime/和id -u核对 UID） - 第三步：
php think route:cache --annotation（注解路由）或php think route:cache（普通配置）
最后一步失败不会报错，只会静默跳过——所以一定要在脚本末尾加验证：访问一个新路由接口，看是否返回 404 还是正常响应。最易忽略的是第二步权限校验，尤其 Docker 容器内 UID 不一致时，route.php 会创建为空文件，后续所有路由匹配都失效。
