YAML适合中大型项目，集中管理、调试方便、版本可控；注解所见即所得但易散落、需装扩展并清缓存；混合使用更优，如主干路由用YAML、具体动作用注解。
路由定义方式选 YAML 还是注解？
YAML 适合中大型项目，所有规则集中在 config/routes.yaml，调试方便、版本可控、团队协作时不易遗漏；注解写在控制器里，所见即所得，但容易随代码散落、难以全局扫描——比如你改了一个 @Route 的 path 却忘了更新相关测试，问题可能到集成阶段才暴露。
用注解必须先装扩展：composer require annotations，且每次修改后要清缓存：php bin/console cache:clear，否则新路由不生效。YAML 则无此限制，改完即热更新（dev 环境下）。
混合使用也常见：主干路由（如 /api、/admin）用 YAML 做前缀和资源导入，具体动作用注解细化。例如：
api_routes: resource: '../../src/Controller/Api/' type: annotation prefix: /api
这样既保持结构清晰，又保留开发灵活性。
动态参数和正则约束怎么写才安全？
路径里的 {id} 默认接受任意非斜杠字符，不加约束等于裸奔。比如 /user/{id} 若没限制，攻击者传 /user/..%2f..%2fetc%2fshadow 可能绕过预期逻辑。
必须显式加 requirements：
- YAML 中：
requirements: { id: '\d+' } - 注解中：
#[Route('/user/{id}', requirements: ['id' => '\d+'])]
注意：正则必须用单引号包裹，否则 PHP 会尝试解析反斜杠；\d+ 比 [0-9]+ 更可靠，避免 Unicode 数字干扰。如果参数可选，路径要加问号：/blog/{slug?}，同时方法参数给默认值：public function show(string $slug = 'home')，两者缺一不可。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
_query 参数生成 URL 时的嵌套陷阱
_query 是生成带查询字符串 URL 的唯一推荐方式，但它只接受数组，且对嵌套层级敏感。传字符串（如 '_query' => 'page=1&sort=asc'）会直接抛 InvalidParameterException。
嵌套数组会被自动转成方括号语法，例如：
$parameters = [
'_query' => [
'filters' => [
'status' => 'active',
'tags' => ['php', 'symfony']
],
'page' => 2
]
];
生成：?filters[status]=active&filters[tags][0]=php&filters[tags][1]=symfony&page=2。但注意：PHP 后端接收时，$_GET['filters']['tags'] 是数组，而某些前端库或代理可能不规范解析方括号，导致数据丢失——这时应改用扁平化键名：'filters_status' => 'active'，由控制器统一解构。
调试路由匹配失败的最快路径
遇到 No route found for "GET /xxx"，别急着翻代码。先跑这句：php bin/console router:debug | grep xxx，看目标路由是否在列表里、HTTP 方法是否匹配、path 是否拼错（比如漏了开头斜杠或大小写不一致）。
若路由存在但不匹配，用 php bin/console router:debug xxx_route_name 查它的真实正则模式——RouteCompiler 会把 /api/{version}/users 编译成类似 #^/api/(?P<version>[^/]+)/users$#s 的表达式，你会发现：如果 version 参数没设 requirements，它默认允许空字符串或含斜杠内容，从而意外匹配到不该进来的路径。
真正难缠的是路由优先级问题：Symfony 按定义顺序匹配，通用路由（如 /blog/{slug}）写在前面，就会吞掉本该由 /blog/new 匹配的请求。解决办法只有调整顺序，或给 /blog/new 加 methods: ['GET'] 和更具体的 requirements 提高权重。
