ParamConverter不会使Category变量为null，要么注入实体要么抛NotFoundHttpException；null通常源于手动查询未处理结果或mapping配置错误。
ParamConverter自动注入实体时，Category变量为什么是null或报错？
它根本不会是null——ParamConverter要么成功查到实体并注入，要么直接抛出NotFoundHttpException，跳过控制器方法执行。如果你看到null，大概率是手动写了查询逻辑但没处理结果，或者误用了@ParamConverter的mapping参数导致匹配失败。
常见踩坑点：
- 实体类没加
#[ORM\Entity]或没被Doctrine扫描到，ParamConverter查不到表结构 - 路由参数名（如
{id}）和实体主键字段名不一致，又没用mapping显式指定，例如实体主键叫uuid却传了id - 用了
requirements={"id"="\d+"}但数据库主键是UUID字符串，正则拦掉了请求，根本进不了ParamConverter环节
什么时候必须放弃@ParamConverter，改用手动查库？
当你需要对“查不到”这件事做**非404响应**时，就必须绕开ParamConverter。它没有钩子、不支持回调，抛异常就是终点。
典型场景包括：
- 用户访问
/post/999，你想重定向到/posts而不是显示404页面 - 需要在查不到时记录审计日志，或触发通知，而不仅是返回错误
- 要根据其他条件联合查询，比如
Post必须是当前用户发布的，不能只靠ID查
这时直接在控制器里用$repository->find($id)或$repository->findOneBy(['id' => $id, 'author' => $this->getUser()])，自己判断结果并决定后续动作。
@ParamConverter注解里class和name参数到底怎么配？
这两个参数控制“谁转给谁”，容易混淆。
class指定要转换成的目标类，比如App\Entity\Post；name指定控制器方法中接收该对象的**形参名**。如果省略name，它会默认取类型提示的变量名（即Post $post → name="post"）。
只有当你类型提示的是接口或父类，或者想把同一个参数转成多个不同对象时，才需要显式写name：
#[Route('/edit/{id}')]
#[ParamConverter('draft', class: App\Entity\Post::class, options: ['mapping' => ['id' => 'id']])]
public function edit(Post $post, Post $draft): Response
上面例子中，一个{id}参数被转了两次：一次给$post（靠类型提示自动），一次给$draft（靠name="draft"显式绑定）。
ParamConverter和路由requirements正则共存时，谁先执行？
路由匹配（含requirements）永远在ParamConverter之前。如果requirements={"id"="\d+"}不满足，请求连控制器都不会进，ParamConverter压根没机会运行。
这意味着：
-
requirements适合做**格式守门员**：确保传入的是数字、UUID格式、日期字符串等 - ParamConverter适合做**存在性检查**：格式对了，再查数据库里有没有这条记录
- 别指望用
requirements代替数据库查询——它不能验证业务逻辑约束，比如“这个ID是否属于当前租户”
真正复杂的校验（如权限、状态、关联有效性）得落到Repository或Service层，ParamConverter只管“找得到 / 找不到”这一层。
