Nginx 的 add_header 必须加 always 参数才对非200响应生效，且需显式拦截 OPTIONS 请求返回 204；ThinkPHP 中间件或 Response 对象会覆盖 Nginx 头部，导致跨域失效。
为什么 Access-Control-Allow-Origin 在 Nginx 里加了还是报跨域？
因为 ThinkPHP 自身的中间件或响应逻辑可能覆盖了 Nginx 设置的头部。Nginx 的 add_header 默认不继承到子请求，且如果 PHP 已经输出了响应头（比如通过 header() 或框架自动写入），Nginx 就不会再生效。
- 确认是否用了
fastcgi_pass：Nginx 的add_header对 FastCGI 后端默认不传递已设置的响应头，需显式开启fastcgi_pass_header或改用always参数 - 检查 ThinkPHP 是否启用了 CORS 中间件：如
think-middleware-cors，它会直接调用header()，优先级高于 Nginx - 用浏览器 DevTools 的 Network → Response Headers 看最终返回的是哪一层写的
Access-Control-Allow-Origin
Nginx 配置 add_header 必须带 always 才有效
ThinkPHP 的错误页、重定向、404 响应等非 200 状态码下，Nginx 默认不发送 add_header 设置的字段。不加 always，跨域头在接口报错时就消失，前端拿不到，直接卡死。
- 正确写法：
add_header Access-Control-Allow-Origin "*" always; - 必须同时设置
Access-Control-Allow-Methods和Access-Control-Allow-Headers，否则预检（OPTIONS）请求失败 - 如果允许携带 Cookie，
Access-Control-Allow-Origin不能为*，得写具体域名，且要加Access-Control-Allow-Credentials: true
ThinkPHP 的 Response 对象会清空 Nginx 头部
框架在构造 Response 实例时，若调用了 withHeader() 或设置了 header 配置项，会触发底层 header() 调用，导致 SAPI 层接管响应头控制权，Nginx 的 add_header 完全失效。
- 排查点：搜索项目中是否在控制器、中间件或全局事件里写了
$response->withHeader('Access-Control-Allow-Origin', ...) - 更稳妥的做法是关掉框架层面的所有 CORS 设置，在 Nginx 统一处理，避免多层覆盖
- 如果必须用框架控制，那就彻底禁用 Nginx 的相关
add_header，只留一条add_header X-Frame-Options "DENY" always;这类无关 CORS 的安全头作验证
OPTIONS 预检请求被 405 拒绝？Nginx 要显式放行
ThinkPHP 默认不注册 OPTIONS 路由，Nginx 收到预检请求后，若没匹配到任何 location 或 fastcgi 指令，会返回 405 Method Not Allowed，而不是把请求转给 PHP。
立即学习“PHP免费学习笔记（深入）”；
- 在 server 或 location 块里加：
if ($request_method = 'OPTIONS') { add_header Access-Control-Allow-Origin "*"; add_header Access-Control-Allow-Methods "GET, POST, OPTIONS, PUT, DELETE"; add_header Access-Control-Allow-Headers "Content-Type, Authorization"; add_header Access-Control-Allow-Credentials "true"; return 204; } - 注意：不要用
rewrite或proxy_pass处理 OPTIONS，容易引发循环或状态码错乱；return 204是最轻量可靠的响应方式 - 确保该
if块位于所有try_files或fastcgi_pass之前，否则不生效
always 参数和 OPTIONS 的显式拦截——这两处一错，跨域就变成“有时行、有时不行”，查起来特别绕。 
