推荐使用 location ^~ /api/ 前缀匹配精准控制 cors 头作用范围，语义明确、性能好、不污染其他路径；敏感子路径可用更长前缀覆盖禁用跨域；禁用 if 判断路径加 header，避免不稳定行为。
直接用 location 前缀匹配是最清晰、最可靠的方式。Nginx 的 location ^~ /api/ 这类语法天然支持“只对特定路径前缀生效”，无需在响应头中做运行时判断，也避免了 if 块嵌套或 map 逻辑的复杂性。
用 ^~ 前缀匹配精准控制作用范围
这是最推荐的做法：把跨域头配置写在专用于该路径前缀的 location 块里，Nginx 会自动只对匹配该前缀的请求生效。
-
^~ /api/表示“以 /api/ 开头的路径优先匹配，且不参与正则排序”，语义明确、性能好、无歧义 - 所有 add_header 指令只在此 location 内生效，不会污染其他路径（如 /static/ 或 /health）
- 配合
always参数确保 204 等非 2xx 响应也能带 CORS 头
禁止某些子路径继承跨域头
如果 /api/ 整体开启 CORS，但其中某个敏感接口（如 /api/v1/admin/delete）必须禁用跨域，就用更精确的 location 覆盖：
- 先定义大范围：
location ^~ /api/ { ... add_header ... } - 再定义高优先级子路径：
location ^~ /api/v1/admin/ { # 不加任何 CORS 头，也不 proxy_pass；或 return 403; } - Nginx 按最长前缀匹配，/api/v1/admin/ 会优先生效，自然跳过父级的 CORS 头
避免用 if 判断路径再加 header
不要写类似 if ($request_uri ~ ^/api/) { add_header ... } 这种结构：
- if 在 location 外部属于“非标准上下文”，add_header 可能不生效或行为不稳定
- if 块内不能安全使用 proxy_pass，易导致 502 或丢失 X-Real-IP 等关键头
- 违背 Nginx 配置设计哲学——路径路由本就是 location 的职责，不该交给 if 模拟
需要动态 Origin 时仍绑定路径前缀
若既要限定路径前缀，又要根据来源域名动态放行（比如只允 https://app.example.com 访问 /api/），可组合使用：
- 用
map $http_origin $cors_origin白名单校验来源 - 把这个 map 变量用在
location ^~ /api/块内的 add_header 中：add_header Access-Control-Allow-Origin $cors_origin always; - 这样既保证只对 /api/ 生效，又保证 Origin 是白名单里的合法值
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
