隐身模式不直接限制fetch，而是切断其依赖的凭证上下文导致认证失败；因cookie不携带、storage不可用、service worker不激活，使鉴权类fetch返回401/403或报securityerror。
隐身模式本身不直接“限制 fetch”，但它会切断 fetch 所依赖的凭证上下文，导致认证失败。关键不是 fetch 被禁用，而是它发出的请求因缺少有效凭证（如 Cookie、localStorage token）而被服务端拒绝——这在登录态维持、接口鉴权类场景中尤为明显。
隐身模式下 fetch 为何拿不到凭证
隐身窗口默认禁用持久化存储并降级权限，直接影响 fetch 的 credentials 行为：
-
Cookie 不自动携带：即使设置了
credentials: 'include'，隐身模式下第三方 Cookie 被默认拦截，且部分浏览器（如 Safari 私密浏览）会直接屏蔽所有 Cookie 发送；若后端依赖 Cookie 做 session 鉴权，fetch 请求将返回 401/403 -
localStorage/sessionStorage 不可用或抛错：某些浏览器在隐身模式中对 Storage API 抛出
SecurityError，若你的 fetch 前逻辑是const token = localStorage.getItem('auth')，代码会中断，后续 fetch 根本不会执行 - Service Worker 不激活：隐身模式下已注册的 Service Worker 不运行，意味着你无法通过它拦截 fetch、注入 token 或缓存 fallback 响应
快速验证是否受凭证限制影响
不用改代码，直接在生产环境做两组对比测试：
- 在常规窗口打开开发者工具 → Network 面板 → 找一个带鉴权的 fetch 请求 → 右键 “Copy as cURL” → 粘贴到终端执行，确认能返回 200
- 在同一页面打开隐身窗口，复现相同操作，观察该 fetch 是否：
- Network 面板中请求状态为
(failed)或pending不结束 - 响应体为空或含
"unauthorized"/"invalid token"字样 - 控制台报错：
Failed to fetch且无具体 status，或出现SecurityError提示 Storage 访问失败
- Network 面板中请求状态为
绕过凭证限制的实用方案
目标是让 fetch 在无 Cookie、无 Storage 的环境下仍能完成认证：
-
把 token 放进 URL 查询参数（适用于短期、低敏感场景）：
fetch('/api/data?token=abc123', { method: 'GET' })，服务端从 query 解析 token -
改用 Authorization 请求头（推荐）：
headers: { 'Authorization': 'Bearer ' + token }，token 可由登录页服务端渲染注入到 JS 变量，避开 Storage 读取 -
服务端生成一次性 endpoint：前端 fetch 前先请求
/api/auth/endpoint获取带签名的临时 URL（如wss://x.y.z/real?sig=xxx&exp=1716400000），再用该地址发起主请求 -
降级处理逻辑：检测隐身环境（
!window.indexedDB && !window.localStorage可粗略判断），对非核心接口改用无需鉴权的公开路径，或提示用户“部分功能需在普通窗口使用”
注意 Edge 和 Firefox 的特殊表现
不同浏览器对隐身模式的实现有差异，需单独留意：
- Edge InPrivate：扩展仍可保存历史记录，但 Cookie 和表单数据关闭窗口即清空；若 fetch 依赖扩展注入的 header，需确认该扩展在 InPrivate 中是否启用（默认禁用）
-
Firefox 严格模式：启用“增强跟踪保护→严格”后，第三方域名 fetch 即使带 credentials 也会被拦截；建议在开发时用
about:config检查privacy.restrict3rdpartystorage是否为 true -
Chrome 无痕：v80+ 后对跨域 fetch 的 referrer policy 更激进，默认设为
strict-origin-when-cross-origin，可能影响某些依赖完整 referrer 校验的后端策略
