当 Web 页面嵌入 App 的 WebView 中时，跨域请求、cookie 授权和安全策略往往会引发隐蔽问题。比如页面在浏览器提交登录接口无误，在 Android 端正常，但在 iOS WebView 中登录无效、认证失败、用户信息获取失败却无报错。调试难度高，因为这类问题通常在控制台看不到错误日志。
本文通过一次真实场景调试实例，分享如何从跨域授权失败入手，使用包括 WebDebugX 在内的工具，逐步排查、定位并修复问题。
一、问题背景：用户登录接口请求返回正常，但未获得授权状态
某项目登录流程中：
- 点击登录按钮后调用
/api/login，响应返回 token； - 浏览器、本地浏览器版本和 Android WebView 中 token 存储正常；
- 但 iOS WebView 中登录状态未生效，页面始终显示未登录状态。
- 控制台未报错，token 已写入 storage，但接口调用始终返回未授权结果。
二、问题初探：确认 token 是否传递成功
步骤一：WebDebugX 注入观察 token 存储行为
通过 WebDebugX 注入并打印：
console.log('Stored token:', localStorage.getItem('authToken'));
确认 token 已成功存储，但仍然无法授权。
步骤二：使用 Charles 抓包查看接口请求
抓包分析后发现，登录后的接口请求头不包含 Authorization: Bearer <token>，表明前端并未加 header 或 header 被浏览器过滤。
三、深入分析跨域授权失败原因
原因一：iOS WebView 默认不发送跨域 Authorization
WKWebView 在某些版本中，若请求带的是跨域 header（尤其 Authorization），默认行为会拦截 header 或清除 token。可能是容器配置未允许跨域 header 加载。
原因二：Authorization header 被 native 拦截或清洗
部分 App 封装用 JSBridge 或 native 拦截 fetch/XHR，将 header 清洗或替换。前端调用正确，但无法真正到达服务器。
四、调试路径与工具协作
| 工具 | 使用方式 | 能力说明 |
|---|---|---|
| WebDebugX | 注入打点观察 token 存储、请求头情况 | 验证 token 是否正确读取、header 是否添加 |
| Charles | 抓包分析 Authorization header 是否发出 | 确认请求头是否正确向服务器传递 |
| Safari Inspector | 查看 fetch/xhr 调用时的 header 字段 | 验证 iOS WebView 是否采纳 header 信息 |
| 客户端日志 | 查看 server request 中是否接收到 token header | 排查 native 层是否重写或拦截 header 调用 |
五、解决方案策略与验证
方案一：跨域 header 发放明确授权声明
前端请求需设置：
fetch(url, {
headers: {
'Authorization': `Bearer ${token}`,
'Access-Control-Allow-Credentials': 'true'
},
credentials: 'include',
});
并确认后端 response header 包含：
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
方案二：客户端允许 WebView 发送自定义 header
iOS App 端需确保：
webView.configuration.setValue(true, forKey: "allowUniversalAccessFromFileURLs")
webView.configuration.setValue(true, forKey: "allowFileAccessFromFileURLs")
并允许跨域 Authorization header。
六、确认修复与结果回归
- 使用 WebDebugX 验证 token header 已正确添加；
- Charles 抓包显示请求头中有带 Authorization；
- 登录后授权状态恢复，用户登录状态正常生效；
- Safari Inspector 和 WebDebugX 控制台均显示
authToken已正确回传并用于后续接口请求。
七、经验总结与实践建议
- 跨域 header 在 iOS WebView 中行为不稳定，需要客户端协同配置；
- 必须将 token 的写入、读取和请求头逻辑都打点验证；
- WebDebugX 是非浏览器环境中观察 header 和 storage 内容的重要调试工具；
- 跨域授权失败，往往不是前端代码问题，而是 header 被过滤或 native 拦截；
- 开发流程中需明确前、后端与客户端的 header 协议与共识。
调试不是调“接口”，而是调“整个请求链条”
当授权失败在浏览器中复现不出来时，说明问题出在 WebView 与浏览器环境的行为差异。调试流程应从 token 存储、请求 header 到 native 拦截，每一步都可观测、都可复现，才能彻底解决问题。
这条跨域授权的调试路径尝试把握关键节点：存储 → header → 请求 → server 返回。借助 WebDebugX、Charles、Safari Inspector 的组合，我们确保用户登录状态在 iOS WebView 中与其他平台一致，提升用户体验稳定性。
希望这篇实战经验对你在处理跨域授权问题时有所帮助，也能辅助团队建立更稳固的调试流程。