NelmioCorsBundle 默认不处理 OPTIONS 预检请求，导致 405 或空白响应；需正确配置 allow_methods、allow_headers、paths，并清除 prod 缓存。
为什么 OPTIONS 预检请求总返回 405 或空白响应
根本原因是 NelmioCorsBundle 默认不处理预检请求（OPTIONS），而是交由 Symfony 内置的 CORS 机制或 Web 服务器拦截。如果你看到 405 Method Not Allowed 或空响应，大概率是路由没匹配到任何控制器，请求直接被拒绝了。
实操建议：
- 确认已启用
nelmio_cors配置块，且allow_origin不是通配符*时，必须显式设置allow_credentials: true（否则浏览器会拒绝响应） - 检查
config/packages/nelmio_cors.yaml中是否漏写了paths匹配规则——比如你只配了^/api/，但实际请求的是/v1/users，那就不会生效 - 确保没有其他中间件（如自定义
kernel.request事件监听器）提前返回了响应，导致 CORS 处理器根本没机会运行
如何让 POST/PUT 带 JSON 的跨域请求通过
这类请求触发预检后，浏览器会先发 OPTIONS，再发真实请求。如果 NelmioCorsBundle 没正确声明允许的 headers 和 methods，预检就失败。
实操建议：
-
allow_methods必须显式包含POST、PUT、PATCH等，不能只写['*']（Symfony 5.4+ 已弃用通配符写法） -
allow_headers至少要包含Content-Type、X-Requested-With；如果前端用了Authorization或自定义 header，也得列进去 - 注意
expose_headers是给前端 JS 读取用的，比如你想在response.headers.get('X-RateLimit-Remaining')中取值，就必须把它加进expose_headers
开发环境 localhost:3000 调用 localhost:8000 报 CORS 错误
这是最典型的“同源策略”误判场景：虽然都是 localhost，但端口不同（3000 vs 8000）即视为不同源，浏览器强制拦截。
实操建议：
- 不要在
allow_origin写http://localhost:3000然后反复刷新——它只对这个 origin 生效，换端口或协议就失效；开发期建议用数组形式：['http://localhost:3000', 'http://127.0.0.1:3000'] - 避免在生产配置里保留
allow_origin: ['*']，尤其当allow_credentials: true同时开启时，浏览器会直接拒绝（这是安全限制，不是 bundle bug） - 如果用的是 Symfony CLI 或 Docker，确认请求确实发到了 Symfony 应用层，而不是被 nginx / apache 提前拦住——可临时加个
dump('cors hit');在CorsListener的onKernelRequest里验证
为什么 dev 环境正常，prod 环境跨域失效
核心差异在于缓存：prod 环境下 Symfony 编译容器并缓存配置，而 NelmioCorsBundle 的配置解析发生在容器编译阶段。改完 nelmio_cors.yaml 后没清缓存，等于什么都没改。
实操建议：
- 每次修改
config/packages/nelmio_cors.yaml后，必须执行php bin/console cache:clear --env=prod（不是--no-debug） - 检查
APP_ENV是否真为prod——Docker 或部署脚本里常硬编码成dev，导致你以为在 prod 实际还在 dev - 确认
nelmio_cors.yaml文件没被环境条件（如when@prod）包裹却漏配，导致 prod 下该文件压根没加载
最常被忽略的一点：CORS 是浏览器施加的限制，服务端日志里通常看不到失败痕迹；要定位问题，得看浏览器 Network 面板里 OPTIONS 请求的 Response Headers 是否含 Access-Control-Allow-Origin，而不是只盯着 200/404 状态码。
