ParamConverter通过固定流程将路由参数自动转为实体：先取值，再调用Repository::find()按主键查询，默认由EntityValueResolver驱动；需满足参数名匹配主键、Doctrine管理实体、正确类型提示三个前提，否则报错或404。
能，但必须满足三个前提：路由参数名与实体类主键字段一致（或显式声明）、实体类被 Doctrine 管理、控制器方法参数做了正确类型提示。否则会报 NoSuchServiceException 或直接 404。
ParamConverter 是怎么自动把 {id} 变成实体的
它不是“猜”，而是按固定流程查库：先从路由参数取值（如 id=123），再用这个值调用对应实体 Repository 的 find() 方法（默认按主键查）。整个过程由 EntityValueResolver 驱动，不依赖 SensioBundle（Symfony 5.4+ 已原生集成）。
- 必须启用
doctrine.orm配置，且实体类带@ORM\Entity注解 - 参数名需匹配路由占位符名（
{product}→Product $product），否则要加#[MapEntity]显式指定 - 若主键不是
id（比如叫uuid），ParamConverter 仍会尝试用id查——这时必须手动配置#[MapEntity(id: "uuid")]
#[MapEntity] 比类型提示更灵活的写法
当路由参数名和实体字段不一致，或需要非主键查找时，#[MapEntity] 是唯一可靠方式。它绕过默认 ID 查找逻辑，支持表达式、自定义条件甚至空值容忍。
-
#[MapEntity(id: "slug")]：用slug字段查（而非默认id） -
#[MapEntity(expr: "repository.findOneBy(['status' => 'active', 'id' => id])")]：手写 DQL 条件 -
#[MapEntity(optional: true)]：找不到时不抛 404，而是注入null，适合可选关联场景
示例：public function show(#[MapEntity(id: "code")] Product $product): Response，对应路径 /product/{code}。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
为什么有时 Product $product 会报 “no such service” 错误
这不是 ParamConverter 失效，而是 Symfony DI 容器误判你在请求一个“服务”，而不是触发参数转换。常见于两种情况：
- 控制器方法没加路由注解（
#[Route]），导致框架跳过 ParamConverter 流程，转而尝试 autowire 实体类（实体不是服务，必然失败） - 用了旧版 SensioFrameworkExtraBundle 但未启用
param_converter配置，或 Symfony 版本 ≥6.4 且禁用了framework.router.strict_requirements - 实体类路径错误或未被
doctrine.orm.mappings扫描到，Repository 根本不存在
验证方法：在控制器里临时加一行 dd($this->container->has('doctrine.orm.default_entity_manager'))，确保 Doctrine 已加载。
真正容易被忽略的是：ParamConverter 只在路由匹配成功后才运行。如果正则约束（requirements）先拦下了非法参数（比如 id 不是数字），根本不会走到实体查找那步——所以 requirements 和 #[MapEntity] 是两层独立校验，缺一不可。
