路由缓存必须手动开启且仅在部署环境生效，需在config/app.php中设置route_check_cache=>true并确保app_debug=>false，再执行php think optimize:route生成缓存文件。
路由缓存必须手动开启，且只在部署环境生效
ThinkPHP5.1 的路由缓存默认是关闭的，即使你写了大量路由规则，不显式启用就等于没用。它不是“写完路由自动缓存”，而是必须在 config/app.php 中设置 'route_check_cache' => true 才会激活。这个配置仅在非调试模式（app_debug => false）下起作用——也就是说，开发时开不了，线上关了 app_debug 才真正加载缓存。
常见错误现象：改完配置、清了 runtime、页面还是慢，route_check_cache 没生效。原因通常是：app_debug 仍为 true，或配置写到了 cache.php 或 route.php 这类错位置。
正确做法：
-
route_check_cache必须放在config/app.php的主数组里（和app_debug同级） - 确保
app_debug => false已生效（检查var_dump(config('app_debug'))） - 不要依赖“自动检测”，每次上线后手动执行一次
php think optimize:route
执行 php think optimize:route 才生成真实缓存文件
开启 route_check_cache 只是“允许缓存”，真正把路由规则编译成静态 PHP 数组并落地到 runtime/route/ 目录，靠的是命令行指令。不运行它，框架每次请求仍要动态解析全部路由定义，性能毫无提升。
立即学习“PHP免费学习笔记（深入）”；
该命令会生成 runtime/route/route.php，内容类似 return ['GET' => [...], 'POST' => [...]]。后续请求直接 require 这个文件，跳过所有正则匹配和闭包执行。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
注意事项：
- 必须在项目根目录执行，且 PHP CLI 环境需与 Web 环境一致（尤其扩展和版本）
- 如果路由中用了闭包（如
Route::get('/', function(){...})），该命令会报错退出——闭包无法序列化，必须改用控制器方法地址（如'index/index'） - 修改路由后，必须重新执行该命令，否则缓存仍是旧规则
延迟解析（url_lazy_route）和路由缓存是两回事
有人混淆 url_lazy_route 和路由缓存，以为开了延迟解析就等于优化了路由性能。其实不然：url_lazy_route => true 是控制“何时注册路由”，比如分组路由只在匹配到对应域名或前缀时才加载；而 route_check_cache + optimize:route 是控制“如何匹配路由”，本质是用数组查表替代正则遍历。
二者可以共存，但目标不同：
- 延迟解析适合路由极多、且天然可分割（如多子域）的场景，减少启动开销
- 路由缓存对所有 URL 匹配路径都有效，是更通用的加速手段
- 开启延迟解析后，
optimize:route仍需执行，否则反向生成 URL（如url('index/index')）可能失败
缓存失效或未命中？先看 runtime/route/ 和请求方法
如果你确认配置和命令都做了，但访问速度没变化，大概率是缓存根本没被用上。排查顺序很明确：
- 检查
runtime/route/route.php是否存在且不为空（空文件=生成失败） - 确认当前请求是 GET 方法（POST/PUT/DELETE 不走路由缓存匹配逻辑）
- 检查 URL 是否匹配任何已定义路由——若走的是默认 PATHINFO 模式（如
/index.php/index/index），路由缓存完全不参与 - 查看日志或临时加
echo 'route loaded from cache'; die;到think\Route的关键路径，确认是否真进了缓存分支
最常被忽略的一点：路由缓存只加速“匹配过程”，不加速控制器执行或模板渲染。如果你的瓶颈在数据库查询或视图编译，单开路由缓存不会让页面变快——得配合 optimize:config、tpl_cache 和数据库查询缓存一起调。
