thinkphp路由按注册顺序逐条匹配，不回溯；一旦命中即终止后续匹配，动态参数路由须置于固定路径之后，域名路由需在闭包内完整重定义，泛域名应置后且显式调用方法。
ThinkPHP路由按注册顺序逐条匹配，不回溯
ThinkPHP 的路由系统没有“最优匹配”或“最长前缀匹配”逻辑，它只做线性扫描：从 route/app.php 第一行开始，逐条比对当前请求 URL 是否符合该规则；一旦匹配成功，立刻执行对应操作，后续所有路由都不再检查。这不是 bug，是设计如此。
常见错误现象：http://example.com/user/123 正常，但 http://example.com/user/create 返回 404 —— 实际上它被前面某条 'user/:id' 吃掉了，create 被当作 $id 传进控制器，而数据库查不到 ID 为 "create" 的记录，最终业务层抛出 404。
- 动态参数路由（如
'user/:id'、'blog/:year/:month'）通配性强，应放在后面 - 固定路径路由（如
'user/create'、'user/edit'、'user/store'）必须前置 - 带可选参数的路由（如
'user/[:id]'）比必填参数更宽泛，也应靠后 - 正则路由（如
['/^user\/(\d+)$/' => 'user/read']）匹配优先级由书写位置决定，不因正则复杂度提升
为什么 [:id] 和 :id 的顺序不能颠倒
ThinkPHP 对参数是否必填极其敏感，且匹配过程是贪婪的：它会优先尝试用最宽松的规则去套 URL。如果把 'user/[:id]' 写在 'user/create' 前面，那么访问 /user/create 时，框架会把 create 当作可选参数 $id 的值，而不是走精确的 create 路由。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
:id表示该段必须存在，URL 必须含/user/123形式 -
[:id]表示该段可有可无，/user和/user/123都能匹配 - 二者共存时，
[:id]实际覆盖了所有:id的可能取值，导致后者永远无法命中 - 多参数组合中混用（如
'blog/:year/[:month]/:day'）会破坏分段对齐，/blog/2026/5可能因缺少:day而直接不匹配
域名路由里嵌套顺序错乱会导致整个子域失效
ThinkPHP 的 Route::domain() 是独立路由空间，不是全局规则叠加。你在 route/app.php 里写了 Route::domain('api.example.com', [...])，但闭包里漏了一条 get('v1/user')，那这个路径就彻底不存在——框架不会退到全局路由里去找。
- 域名闭包内必须重新定义该域下所有需要的路由，不能依赖外部定义
- 泛域名（如
*.example.com）需显式调用$r->get()等方法，不能只写数组 - 精确域名（如
admin.example.com）应放在泛域名之前，否则后者会提前捕获所有子域请求 - 本地开发时，
HTTP_HOST包含端口（如localhost:8000），域名路由必须完全匹配，否则不触发
路由缓存让顺序问题更隐蔽
执行过 php think optimize:route 后，所有路由规则被编译进 runtime/route.php。此时修改 route/app.php 但忘记重生成缓存，你看到的其实是旧顺序——新调整的路由根本没加载，排查时容易误判为语法或配置问题。
- 上线前必须跑一次缓存命令，否则每次请求都要全量解析，性能差且顺序不可控
- 开发阶段可临时关掉缓存（设
'route_cache' => false），方便实时验证顺序效果 - 用
php think route:list查看实际生效的路由列表，确认目标路径是否在预期位置、name 是否为空 - 改完路由后，别只刷新页面，先清缓存再验证，否则你调试的可能是“幻影路由”
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
