Laravel 8.9升级后请求不存在模型返回200而非404问题排查

根据你描述的场景——仅在 php artisan serve + 前端测试、Bitbucket CI 流水线中出现异常，本地测试和 Laravel HTTP 测试正常——我整理了几个针对性的排查方向和解决方案：

1. 优先检查自定义异常处理器 #

findOrFail 本身会抛出 ModelNotFoundException，Laravel 默认会自动将其转换为 404 响应，但如果升级后修改了异常处理逻辑，可能会覆盖这个默认行为：

• 打开 app/Exceptions/Handler.php，检查 render 方法中是否有针对 ModelNotFoundException 的自定义处理，比如不小心把状态码设成了 200：

  use Illuminate\Database\Eloquent\ModelNotFoundException;
  
  public function render($request, Throwable $exception)
  {
      // 错误示例：这里返回了200而不是404
      if ($exception instanceof ModelNotFoundException) {
          return response()->json(['message' => '资源不存在'], 200);
      }
  
      return parent::render($request, $exception);
  }
  

• 如果没有自定义处理，确认没有覆盖 Laravel 默认的异常处理逻辑——比如是否移除了 parent::render() 调用，导致异常没有被正确转换。

2. 排查全局中间件的响应篡改 #

有些中间件会在最后统一修改响应状态码，这可能会把 404 强制改成 200：

• 列出 app/Http/Kernel.php 中的全局中间件，逐个检查 handle 方法，看是否存在类似这样的代码：

  return $next($request)->setStatusCode(200);
  

• 重点关注处理响应格式化、跨域的中间件，这类中间件容易出现统一修改状态码的逻辑。

3. 针对 CI 流水线的特殊排查 #

既然本地（包括镜像内）测试正常，CI 环境的差异是关键：

• 检查环境变量：确认 CI 中的 APP_DEBUG、APP_ENV 配置是否和本地一致。虽然 DEBUG 模式不影响状态码，但某些自定义逻辑可能会根据环境修改响应。
• 添加调试日志：在 Handler.php 的 render 方法中加入日志，追踪异常处理的完整流程：

  public function render($request, Throwable $exception)
  {
      \Log::info("捕获异常：" . get_class($exception));
      \Log::info("异常消息：" . $exception->getMessage());
      
      $response = parent::render($request, $exception);
      \Log::info("最终响应状态码：" . $response->getStatusCode());
  
      return $response;
  }
  

  执行 CI 流水线后查看日志，就能知道异常是否被正确识别，以及状态码在哪一步被修改。
• 清除路由缓存：在 CI 脚本中加入 php artisan route:clear，避免旧的路由缓存导致异常路由匹配。

4. 验证 PHP 内置服务器的特殊行为 #

php artisan serve 使用的是 PHP 内置服务器，和 Nginx/Apache 存在细微差异：

• 用 curl 直接请求异常接口，查看原始响应头：

  curl -I http://localhost:8000/your-event-endpoint/999999
  

  如果本地用 serve 也能复现问题，可以进一步调试中间件的执行顺序，看是否有中间件在响应发送前篡改了状态码。

5. 排除资源类的干扰 #

虽然 findOrFail 抛出异常后不会走到返回资源的步骤，但可以临时注释掉 EventResource，直接返回模型：

public function findOne($eventId) { 
    $event = Event::withMailRecords()->withContacts()->withContingents()->findOrFail($eventId); 
    return $event; // 临时替换资源类
}

如果状态码恢复正常，再排查 EventResource 中是否有异常的空数据处理逻辑。

内容的提问来源于stack exchange，提问作者flxbe