ThinkPHP路由按定义顺序匹配，先定义的规则优先执行。应将静态路径如user/profile置顶，通配符规则如user/:id置于其后，兜底规则user/*放最后，正则约束不改变顺序逻辑。
路由规则为什么没按预期生效
ThinkPHP 的路由匹配是**从上到下顺序扫描**，遇到第一个能匹配的规则就立即执行，后续规则不再检查。这不是“优先级数字越大越优先”，而是纯靠定义顺序——写在前面的规则拥有绝对优先权。
常见错误现象：Route::get('user/:id', ...) 写在 Route::get('user/profile', ...) 前面，结果访问 /user/profile 时被当成 user/:id 匹配，:id 值变成字符串 "profile"，逻辑崩了。
- 所有通配符（
:id、*<code>、<code>[:ext]）都属于“宽匹配”，必须放在更具体规则之后 - 带正则约束的规则（如
[:id\d+]）仍服从顺序，不能靠正则“抢优先” - 分组路由（
Route::group）内部也遵循同样顺序规则，组间顺序由注册先后决定
怎样手动控制路由匹配顺序
最可靠的做法就是**把高确定性、低泛化性的规则写在前面**，比如固定路径、带明确后缀或前缀的路由；把含变量、通配符、可选参数的规则统一挪到后面。
示例：以下顺序才是安全的：
立即学习“PHP免费学习笔记（深入）”；
Route::get('user/profile', 'User/profile');
Route::get('user/settings', 'User/settings');
Route::get('user/:id', 'User/read');
Route::get('user/:id/edit', 'User/edit');
Route::get('user/*', 'User/other');
-
user/profile和user/settings是完全静态路径，必须置顶 -
user/:id必须在user/:id/edit之前——否则/user/123/edit会被截成:id = "123/edit" -
user/*是终极兜底，必须放最后，否则它会吃掉所有user/xxx请求
使用 Route::rule() 时要注意什么
Route::rule() 支持自定义正则和闭包，但**不改变匹配顺序逻辑**，只是扩展了单条规则的表达能力。它容易让人误以为“加了正则就能更精确”，其实只要位置靠前，哪怕正则写得再严，也会拦住后面本该更匹配的规则。
- 不要用
Route::rule('user/:id', ..., ['id' => '\d+'])替代把user/:id往后放——正则只校验，不参与排序 - 如果需要动态排除某些字面量（如禁止
user/profile被:id匹配），得靠顺序 + 静态规则双保险，不是靠正则“过滤” -
Route::miss()是最终未命中时的兜底，但它在所有已注册规则跑完后才触发，不影响中间顺序
调试路由匹配过程的实用方法
ThinkPHP 没有内置“路由匹配日志”，但可以通过 Route::rules() 获取当前全部注册规则，再结合请求路径人工模拟匹配流程。
快速验证方式：
dump(Route::rules()); // 查看规则数组，注意键名顺序即匹配顺序
- 规则数组的键是原始定义字符串（如
"user/:id"），值是解析后的完整配置，顺序不可靠，得看var_export(Route::rules(), true)输出的数组索引 - 开发期可在
app/route.php开头加echo "Loading routes...\n";，配合php think route:list命令交叉比对 - 线上环境慎用
Route::rules()，它返回的是运行时结构，可能含闭包，直接 dump 易报错
真正难处理的，是跨模块、多文件注册路由时的隐式顺序——route.php 加载顺序、Route::import() 的调用点、以及命令行模式下是否加载了测试路由，这些地方稍不注意，规则就乱了。
