NelmioCorsBundle是Symfony最稳妥的CORS方案，但配置错误（如漏配paths、allow_origin格式不对）会导致OPTIONS预检失败、405错误或无响应；根本原因是Bundle默认不接管未匹配paths的OPTIONS请求，使其落入路由层而无对应处理。
直接上结论：用 NelmioCorsBundle 是 Symfony 项目最稳妥的 CORS 方案，但配置错一个参数（比如漏掉 paths 或写错 allow_origin 格式），就会导致 OPTIONS 预检失败、405 错误或前端拿不到响应头。
为什么 OPTIONS 请求总返回 405 或空白响应
根本原因不是 Symfony 拦截了，而是 NelmioCorsBundle 默认不接管 OPTIONS 请求——它只在匹配到 paths 规则且请求是跨域时才注入响应头；如果没匹配上，请求就落到路由层，而你又没定义 OPTIONS 路由，结果就是 405 或空响应。
- 检查
config/packages/nelmio_cors.yaml中的paths是否覆盖真实请求路径，例如前端调的是/v1/users，但配置里只写了^/api/，那就完全不生效 -
allow_origin如果不是'*'，必须同时设allow_credentials: true，否则浏览器会静默丢弃响应（即使后端返回了 200） - 确认没其他事件监听器（比如自定义
kernel.request）提前return了响应，导致 CORS 处理器根本没运行
POST/PUT 带 JSON 的请求过不了预检
这类请求触发预检时，浏览器会先发 OPTIONS，并带上 Access-Control-Request-Method 和 Access-Control-Request-Headers。如果 Bundle 没声明允许对应方法和头，预检就直接失败。
-
allow_methods必须显式列出POST、PUT、PATCH等，Symfony 5.4+ 已禁用['*']写法 -
allow_headers至少包含Content-Type、X-Requested-With；如果前端发了Authorization或自定义 header（如X-Api-Version），也得加进去 -
expose_headers只影响前端 JS 能否读取响应头，比如你想用response.headers.get('X-RateLimit-Remaining')，就必须把它加进这个列表
开发环境 localhost:3000 调用 localhost:8000 报 CORS
这是最典型的“同源策略”误判：协议+域名+端口三者任一不同即算跨域。localhost:3000 和 localhost:8000 端口不同，浏览器强制拦截。
- 开发期别写死单个 origin，用数组：
allow_origin: ['http://localhost:3000', 'http://127.0.0.1:3000'] - 生产环境严禁
allow_origin: ['*']+allow_credentials: true同时开启，浏览器会直接拒绝（不是 bug，是安全限制） - 确认请求真到了 Symfony 层：如果是 Docker 或 Nginx，临时在
CorsListener::onKernelRequest里加dump('cors hit');，看是否执行——没输出说明被 Web 服务器提前拦了
真正容易被忽略的是 paths 的正则匹配逻辑和 origin_regex 的开关时机：默认 origin_regex: false，但一旦用了正则表达式（比如 ^https?://(localhost|127\.0\.0\.1)(:[0-9]+)?$），就必须手动打开它，否则整个规则失效。
