在 Nginx 中需在 location 块内精准匹配静态资源路径（如 location ~ .(js|css|woff2|ttf|png)$），添加带 always 的 CORS 响应头，显式处理 OPTIONS 预检请求并返回 204，禁用 与 Access-Control-Allow-Credentials true 混用，且避免在 server 或 http 全局块配置以防污染。
在 Nginx 中，location 块是控制静态资源跨域行为的核心配置单元。它决定哪些请求路径能被匹配、响应头如何注入、预检请求是否被正确拦截并返回，直接关系到浏览器能否成功加载 JS、CSS、字体、图片等跨域资源。
精准匹配静态路径，避免全局污染
不要把 CORS 头加在 server 块顶层——那样会作用于所有响应，包括 HTML 页面或 API 接口，容易引发安全或兼容性问题。应只针对真实提供静态文件的路径做配置：
- 用前缀匹配：如
location /static/ { ... }，配合alias /var/www/static/;或root /var/www; - 用正则匹配具体后缀：如
location ~* \.(js|css|woff2|ttf|png|jpg|gif)$ { ... }，更细粒度控制字体、脚本等资源 - 确保
add_header出现在匹配块内，且不被嵌套if或其他指令意外覆盖
正确设置 Access-Control-Allow-Origin
这个头决定了前端页面能否读取响应内容，必须与前端实际部署域名严格对应：
- 若前端固定在
https://app.example.com，写成：add_header 'Access-Control-Allow-Origin' 'https://app.example.com' always; - 禁用
*与Access-Control-Allow-Credentials true同时出现——否则浏览器直接拒绝响应 - 如需支持多个可信域名，可借助变量动态设置（如通过
map指令映射$http_origin），避免硬编码或重复配置
必须显式处理 OPTIONS 预检请求
当请求含自定义头（如 Authorization）、非简单方法（如 PUT）或 withCredentials: true 时，浏览器会先发一个 OPTIONS 请求。Nginx 若未响应，会导致请求直接失败：
- 在同一个
location块内添加if ($request_method = 'OPTIONS') { ... return 204; } - 响应体必须为空，状态码为
204 No Content，且需带上完整 CORS 头（包括Origin、Methods、Headers等） - 注意：
if在location内可用，但在server级慎用；优先保证预检响应头与主响应头一致
补充关键响应头提升兼容性
仅配 Allow-Origin 不足以覆盖所有场景，尤其对字体加载、断点续传、带凭据请求等：
-
Access-Control-Allow-Methods：静态资源通常只需GET, HEAD, OPTIONS -
Access-Control-Allow-Headers：列出前端实际发送的头，如DNT,User-Agent,X-Requested-With,Content-Type,Range -
Access-Control-Expose-Headers：让前端 JS 能读取服务端返回的特定头，例如Content-Length和Content-Range对字体分片或视频加载很关键 -
Vary: Origin：配合 CDN 或反向代理缓存，确保不同源的响应不被错误复用
