在Nginx中通过add_header配置CORS头是解决静态资源跨域最直接方式，需置于匹配静态路径的location块，明确指定Origin（禁用*配合credentials），并显式处理OPTIONS预检请求，避免头被覆盖或丢失。
在 Nginx 中通过 add_header 设置 Access-Control-Allow-Origin，是解决静态资源（如 JS、CSS、图片）跨域请求最直接有效的方式。关键在于正确配置位置、避免重复添加、注意通配符限制，以及配合其他 CORS 头使用。
确保 add_header 放在正确的配置块中
add_header 指令只在它所在的上下文（server、location）生效，且不会继承上级配置。如果只为静态资源开启 CORS，应放在匹配静态文件的 location 块里，而不是全局 server 块：
- ✅ 推荐：针对 /static/ 或具体后缀（.js/.css/.png）设置
- ❌ 避免：仅写在 server 块却未覆盖所有静态路径，导致部分资源仍被拦截
设置允许的源，慎用通配符 *
若前端部署在固定域名（如 https://app.example.com），应明确指定来源：
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
add_header Access-Control-Allow-Origin "https://app.example.com";
add_header Access-Control-Allow-Methods "GET, HEAD, OPTIONS";
add_header Access-Control-Allow-Headers "DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range";
add_header Access-Control-Expose-Headers "Content-Length,Content-Range";
}
⚠️ 注意：* 只适用于简单请求且不带凭证（credentials）的情况。若前端设置了 withCredentials: true，必须指定具体域名，不能用 *，否则浏览器会拒绝响应。
处理预检请求（OPTIONS）
浏览器对非简单请求（如含自定义 header、PUT/DELETE 方法）会先发 OPTIONS 请求。Nginx 默认不响应 OPTIONS，需显式返回 204：
- 在对应 location 中添加
if ($request_method = 'OPTIONS') { add_header Access-Control-Allow-Origin "https://app.example.com"; add_header Access-Control-Allow-Methods "GET, POST, OPTIONS"; add_header Access-Control-Allow-Headers "DNT,User-Agent,X-Requested-With"; add_header Access-Control-Max-Age 86400; add_header Content-Length 0; add_header Content-Type text/plain; return 204; } - 或更简洁地用
try_files+ 空响应，但需确保不干扰真实资源路由
避免 add_header 被覆盖或丢失
add_header 在子请求（如 error_page、rewrite 后的内部跳转）中不生效；另外，如果同一 location 有多个 add_header，只有最后一个同名头会被保留。建议：
- 集中管理 CORS 头，避免分散书写
- 检查是否被
error_page 404 /404.html类配置覆盖——静态资源 404 时，CORS 头可能丢失，可加add_header到 error_page 对应的 location 中 - 用 curl 或浏览器开发者工具验证响应头是否真实存在，而非仅看配置文件
