Doctrine 查询返回 null 不抛异常，404 是因显式调用 createNotFoundException()、ParamConverter 自动触发或自定义监听器拦截所致，需逐层排查控制器逻辑、注解配置及事件监听。
Doctrine 查询没查到数据，控制器却抛出 404，这不是 Doctrine 的错，而是你主动或隐式触发了 Symfony 的“找不到资源就 404”逻辑——常见于 find() 返回 null 后直接调用方法、或手动 throw $this->createNotFoundException() 却没意识到它已被封装进业务流程。
检查 find() 后是否对 null 做了非法操作
Doctrine 的 find()、findOneBy() 等方法查不到时返回 null，不是异常。若后续代码直接调用 $entity->getName() 或 $entity->getId()，PHP 会报 Fatal error: Call to a member function on null。但 Symfony 默认将此类致命错误渲染为 500 页面；只有当你显式处理了 null 并抛出 NotFoundHttpException，才会显示 404。
- 确认控制器里有没有类似
if (!$entity) { throw $this->createNotFoundException(); }——这是最常见来源 - 检查是否用了
findOrFail()（注意：Symfony 2 原生不提供该方法，可能是你自定义的 Repository 方法，或引入了第三方扩展） - 留意 Twig 模板中是否写了
{{ entity.name }}而 entity 为 null，且开启了 strict_variables：这会导致模板层抛出Twig_Error_Runtime，默认被转成 500；但若你在 exception listener 中把它转成了 404，也会表现为 404
排查路由与参数绑定是否意外触发空查询
URL 中的 ID 参数被解析后传入查询，但该 ID 根本不存在于数据库，又没做存在性校验，就容易形成“查不到 → 抛 404”的链路。
- 比如路由定义为
/post/{id}，用户访问/post/999999，而数据库最大 id 是 100 - 检查是否在
loadUserByUsername()、getUser()等安全相关方法中做了类似逻辑：查不到用户就 throw 404，这会影响整个认证流程 - 确认是否启用了
ParamConverter（如 SensioFrameworkExtraBundle），它会在控制器方法参数上自动执行find()，并在失败时默认抛NotFoundHttpException
验证是否被 ParamConverter 或自定义监听器拦截
Symfony 2 常用 SensioFrameworkExtraBundle 提供 @ParamConverter 注解，它会根据路由参数自动查找实体。一旦找不到，默认行为就是抛 404。
- 查看控制器方法是否有类似
@ParamConverter("post", options={"mapping": {"id": "id"}})的注解 - 检查
config.yml中是否配置了sensio_framework_extra:→request:→converters: true（默认开启） - 搜索项目中是否注册了自定义的
kernel.request或kernel.controller监听器，它们可能在控制器执行前就根据 ID 查库并提前终止流程
快速定位：加一行日志就能确认源头
在抛 404 的控制器方法开头加一句日志，看请求是否真进了这个方法：
$this->get('logger')->info('PostController::show called with id='.$id);- 如果日志没出现，说明 404 是在控制器执行前发生的（大概率是 ParamConverter）
- 如果日志出现，再在
find()后加if (!$entity) { $this->get('logger')->warning('Entity not found for id:'.$id); }，确认是不是你写的逻辑
