CORS错误源于服务端未返回合规响应头，需检查Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers三项是否齐全且配置正确。
宙斯浏览器控制台报出“Blocked by CORS policy”，页面拿不到API返回的JSON数据，说明请求已发到服务端并收到200响应，但浏览器在解析响应体前因缺少合规跨域头而主动丢弃——这不是前端代码问题，而是服务端未按CORS协议返回必要响应头。
确认是否为CORS响应头缺失
这一步不操作浏览器，直接验证问题根源：是前端发不出请求，还是后端没回正确头？
按下 Ctrl+Shift+I（Windows/Linux）或 Cmd+Option+I（macOS）打开开发者工具 → 切换到 Network 标签页 → 刷新页面 → 点击那个报 CORS 错误的请求 → 在右侧 Headers 面板中展开 Response Headers → 查找 Access-Control-Allow-Origin 字段。
若该字段完全不存在，或值为 * 但请求携带了 credentials（如 Cookie），或值为具体域名却与当前网页协议/端口不匹配（比如网页是 https://a.com，而头里写的是 http://a.com），就坐实了服务端响应头配置错误。此时浏览器拒绝解析响应体，连 JSON 都看不到。
服务端必须配置的三项响应头
仅靠前端加代理或改请求方式无法绕过同源策略本质限制，必须让服务端返回合规响应头。以下三项缺一不可：
Access-Control-Allow-Origin必须明确指定允许的源（如 https://your-site.com），不能写 * 同时又带 credentials；若允许多个源，需后端动态读取 Origin 请求头并白名单比对后回写。
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
Access-Control-Allow-Methods必须包含实际用到的 HTTP 方法（如 GET, POST, PUT），尤其非简单请求（如带 Authorization 头的 GET）会触发预检，OPTIONS 方法必须显式列出。
Access-Control-Allow-Headers若前端设置了自定义请求头（如 X-Auth-Token），此头必须精确列出这些字段名，否则预检失败。
本地调试时临时绕过验证
正式环境绝不能依赖此法，但本地调试接口时可快速验证是否纯属CORS问题。
方法一：启用宙斯浏览器本地调试模式
在地址栏输入 zeus://flags → 搜索 enable-web-security → 将其设为 Disabled → 点击右下角 Relaunch 重启浏览器。此操作关闭全部CORS检查，所有跨域请求放行，但仅限本机单人调试，切勿用于访问真实账号或敏感系统。
方法二：使用支持CORS代理的在线服务
将原始请求URL中域名部分替换为代理地址，例如原请求是 https://api.example.com/data → 改为 https://corsproxy.io/https://api.example.com/data。
