safari 对 cors 校验更严格，需后端精确匹配 access-control-allow-origin、返回 access-control-allow-credentials: true、正确处理预检及 samesite=none; secure cookie。
当你在 Safari 浏览器中调试前端应用时，发现 fetch 或 XMLHttpRequest 请求返回“CORS policy: No 'Access-Control-Allow-Origin' header is present”错误，且该接口在 Chrome 中能正常访问，说明问题出在 Safari 对 CORS 的校验更严格——它会拦截缺少 Vary: Origin 响应头、或预检请求（preflight）未通过的跨域请求，尤其在启用了 `credentials: 'include'` 时。
确认 Safari 是否真正拦截了请求
打开 Safari 开发者菜单（Safari → 偏好设置 → 高级 → 勾选“在菜单栏中显示‘开发’菜单”），然后按 Option+Cmd+I 打开 Web 检查器 → 切换到“网络”标签页 → 刷新页面 → 找到报错的请求 → 点击它 → 查看“标头”面板中的“响应标头”。
如果 Response Headers 中完全缺失 【Access-Control-Allow-Origin】，说明后端根本没返回 CORS 头；如果存在但值为 *，而请求又携带了 credentials（如 cookies），则 Safari 会直接拒绝——这是规范强制行为，不是 bug。
后端必须添加的关键响应头
当你的前端请求设置了 credentials: 'include'（例如登录态需传 cookie），后端响应必须同时满足以下三点：
① Access-Control-Allow-Origin 不能为 *，必须精确匹配请求来源（如 https://your-app.com）；
② 必须显式返回 Access-Control-Allow-Credentials: true；
③ 若请求含自定义标头（如 Authorization、X-App-Version），还需返回 Access-Control-Allow-Headers，并列出所有允许字段；
④ 若使用 PUT/DELETE 方法或 Content-Type 为 application/json，Safari 会先发 OPTIONS 预检请求——后端必须正确响应 OPTIONS 请求，且返回的 Access-Control-Max-Age 建议设为 86400（避免频繁预检）。
临时绕过（仅限本地开发）
方法一：启动 Safari 时禁用 Web 安全（仅 macOS 14 及以下有效）
关闭所有 Safari 窗口 → 在终端执行：open -a Safari --args --disable-web-security --user-data-dir=/tmp/safari-dev → 此时新 Safari 实例将跳过 CORS 检查。
【警告：此模式下任何网页均可读取你其他标签页的 localStorage 和 cookies，切勿用于日常浏览或含敏感信息的页面】
方法二：用本地代理转发请求（推荐）
安装 http-proxy-middleware，在 vite.config.ts 或 webpack.dev.js 中配置代理规则，把 /api/ → http://localhost:3000/api/，让请求走同源路径，彻底规避 CORS。
检查 Safari 特有行为
Safari 会对带有 credentials 的跨域请求额外校验 Cookie 的 SameSite 属性。如果后端 Set-Cookie 中未声明 SameSite=None; Secure，则 Safari 会拒绝发送该 Cookie —— 即使 CORS 头全部正确，fetch 也会因认证失败而报 401 或空响应。
验证方式：在 Web 检查器 → “存储” → “Cookie” 中查看目标域名下的 Cookie 是否标记为 “SameSite: None” 且 “Secure: true”。若没有，请后端在 Set-Cookie 响应头中补全：Set-Cookie: session=xxx; Path=/; Domain=.example.com; Secure; HttpOnly; SameSite=None。
