最基础方式是构造Response对象时传整数状态码参数：new Response($content, 404)；JsonResponse同理用new JsonResponse($data, 404)；抛内置HttpException异常可自动映射状态码并触发统一异常处理。
控制器里直接 new Response() 时怎么设状态码
最基础的方式就是构造 Response 对象时传第二个参数：new Response($content, 404)。这个数字就是 HTTP 状态码，不加默认是 200。
常见错误是写成字符串 "404" 或漏掉参数导致返回 200 OK 却被前端当成成功处理。
- 状态码必须是整数，不是字符串
- 如果内容为空但需要特定状态码，用
new Response('', 401) - 不要依赖“没传就自动推断”——它不会推断，永远是 200
用 JsonResponse 返回 JSON 时怎么带状态码
JsonResponse 构造函数的第二个参数就是状态码，和 Response 一致，但第三个参数才是响应头（可选）。
例如：new JsonResponse(['error' => 'not found'], 404)，这样既返回 JSON 数据，又确保状态码正确，前端能靠状态码做统一错误拦截。
- 别在 body 里塞
"status": 404然后返回 200——这破坏 HTTP 语义，API 客户端无法靠状态码分流 - 若用
$this->json()（Symfony 5.2+），它也支持第二个参数：$this->json($data, 400) - 注意：即使数据是空数组或
null，状态码仍生效；JsonResponse会安全序列化它们
抛异常时怎么让 Symfony 自动映射到对应状态码
Symfony 内置异常类已绑定标准状态码，比如抛 NotFoundHttpException 就是 404，AccessDeniedHttpException 是 403。框架在异常处理器中自动读取 $exception->getStatusCode()。
关键点在于：别自己 new Response(‘’, 404) 后 return，那样绕过了异常处理流程，日志、监控、格式协商（如 Accept: application/json）全失效。
- 抛异常比手动设状态码更利于统一治理（比如所有 404 都走同一个 JSON 错误模板）
- 自定义异常需继承
HttpException并实现getStatusCode()方法 - 确保
kernel.exception事件监听器已启用，否则异常会被转成 HTML 500 页面（尤其在 API 场景下很危险）
为什么有时状态码对了但响应头里的 Allow 不对
当路由存在但方法不匹配（比如 POST 访问只声明了 GET 的路由），Symfony 自动返回 405，并在响应头里写 Allow: GET, HEAD。这个 Allow 值来自路由配置的 methods 选项，不是控制器决定的。
如果你看到 405 但 Allow 头缺失或错误，说明路由没正确定义 methods，或者用了通配符路由覆盖了精确匹配。
- 注解方式必须写
@Route("/path", methods={"GET"})，不能只写路径 - YAML 路由里要显式加
methods: [GET]，否则默认接受所有方法，405 不会触发 -
Allow头只由路由层生成，控制器 throw 出的异常不会补这个头
实际项目中最容易忽略的是：状态码设对了，但没配合内容类型协商或异常处理链路，导致 API 返回 HTML 错误页、日志里看不到结构化错误字段、前端无法靠状态码做自动化重试。这些不是“设不设”的问题，而是“在哪一层设、由谁负责设”的分工问题。
