Kubernetes Ingress Controller（如 Nginx）需拦截并响应 OPTIONS 预检请求，返回 204 状态码及合规 CORS 头（如 Access-Control-Allow-Origin、Allow-Methods），避免透传至未实现 OPTIONS 的后端；可通过标准注解（如 enable-cors、cors-allow-origin）或 configuration-snippet 精细配置，验证时需确认浏览器收到状态码 204 及匹配的响应头。
Kubernetes Ingress 本身不直接处理 OPTIONS 预检请求，而是由背后的 Ingress Controller（通常是 Nginx Ingress Controller）来响应。关键在于正确配置注解或自定义规则，让 Controller 在收到 OPTIONS 请求时返回合规的 CORS 响应头，而不是转发给后端服务。
Ingress Controller 必须拦截并响应 OPTIONS 请求
浏览器发起跨域非简单请求前，会先发一个 OPTIONS 预检请求。如果这个请求被错误地转发到后端服务，而服务又没实现 OPTIONS 处理逻辑，就会返回 404 或 500，导致跨域失败。因此，Ingress Controller 需在网关层就完成响应：
- 不把 OPTIONS 请求透传给后端，避免后端未实现时出错
- 对匹配路径的 OPTIONS 请求，立即返回 204 状态码 + 正确的 CORS 响应头
- 响应头必须包含 Access-Control-Allow-Origin、Allow-Methods、Allow-Headers 等，且值要与实际请求一致
用标准注解启用并控制预检行为
Nginx Ingress Controller 提供了一组开箱即用的 CORS 注解，无需写自定义 snippet 就能覆盖大多数场景：
- nginx.ingress.kubernetes.io/enable-cors: "true" —— 开启全局 CORS 支持
- nginx.ingress.kubernetes.io/cors-allow-origin —— 指定允许的源，带 credentials 时不能填 *，需写具体域名如 https://app.example.com
- nginx.ingress.kubernetes.io/cors-allow-methods —— 明确列出允许的方法，默认已含 OPTIONS，但建议显式写出 GET, POST, PUT, DELETE, OPTIONS
- nginx.ingress.kubernetes.io/cors-max-age —— 设置预检结果缓存时间（单位：秒），例如 86400 表示一天内不再重复发 OPTIONS
- nginx.ingress.kubernetes.io/cors-allow-credentials: "true" —— 若前端设了 withCredentials，此项必须为 true，且 origin 不能是 *
需要精细控制时用 configuration-snippet
当标准注解不够用（比如要动态响应 Origin、或对不同 path 做差异化处理），可在 Ingress 的 annotations 中添加 nginx.ingress.kubernetes.io/configuration-snippet：
- 用 if 判断 $request_method = 'OPTIONS'，然后 set header 并 return 204
- Access-Control-Allow-Origin 可设为 $http_origin 实现动态回写，避免硬编码多个域名
- Access-Control-Allow-Headers 推荐设为 *，或明确列出前端实际用到的头（如 Authorization、X-Request-ID）
- 注意：return 204 后必须终止流程，不能继续 proxy_pass
验证预检是否生效的要点
真正起作用的不是“有没有配”，而是浏览器能否收到合法响应：
- 打开浏览器开发者工具 → Network 标签页，筛选 OPTIONS 请求，确认状态码是 204（不是 200 或 404）
- 检查响应头中 Access-Control-Allow-Origin 是否匹配前端页面地址
- 确认 Access-Control-Allow-Methods 包含你实际要用的动词（比如 PUT）
- 若带 cookie，检查 Access-Control-Allow-Credentials 是否为 true，且 Origin 不是 *
