第三方统计脚本跨域上报需后端配置CORS响应头，关键在于Access-Control-Allow-Origin（不可为*）、Allow-Methods、Allow-Headers、Allow-Credentials=true；OPTIONS预检须返回204并带全CORS头，前端避免冗余header和no-cors模式。
第三方统计脚本（如埋点 SDK、性能监控 JS）向非同源后端上报数据时，常因浏览器同源策略被拦截——这不是脚本写错了，而是浏览器在收到响应后拒绝把结果交给 JavaScript 读取。CORS 不是用来“绕过”限制的工具，而是让服务端明确告诉浏览器：“这个来源的脚本，允许它拿到我的响应”。所以关键不在前端怎么发，而在后端是否配合返回正确的响应头。
统计请求为什么容易触发 CORS 问题
大多数统计上报使用 fetch 或 XMLHttpRequest 发送 POST 请求，且常带以下特征：
- Content-Type 设为
application/json（非简单类型，触发预检 OPTIONS） - 携带自定义 header，如
X-Tracker-Version或Authorization - 需要附带 Cookie（如用户会话标识），即设置
credentials: 'include'
这些都会导致浏览器先发一个 OPTIONS 预检请求；如果服务端没处理或响应头缺失，主请求根本不会发出，控制台显示 preflight is invalid 或 net::ERR_FAILED。
后端必须配置的核心响应头
统计接口的服务端需在所有响应（包括 OPTIONS 和实际 POST）中返回：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
-
Access-Control-Allow-Origin：不能填
*（因上报通常需带凭证），应设为具体域名，如https://your-site.com；若多端共用（PC/APP/H5），可动态匹配白名单 -
Access-Control-Allow-Methods：至少包含
POST, OPTIONS -
Access-Control-Allow-Headers：列出前端实际发送的 header，如
Content-Type, X-Tracker-ID, Authorization -
Access-Control-Allow-Credentials：值必须为
true（与credentials: 'include'对应） -
Access-Control-Max-Age（可选）：缓存预检结果，减少重复 OPTIONS 请求，例如
86400
对 OPTIONS 请求，建议直接返回 204 No Content，不走业务逻辑，只写响应头。
前端 SDK 的适配要点
统计脚本自身也要避免无意触发更严格的校验：
- 上报地址尽量用相对路径或同源地址（开发期可用代理，如 Vite 的
server.proxy将/collect转发到后端） - 如无需 Cookie，显式设
credentials: 'omit'，此时Access-Control-Allow-Origin: *可用 - 避免在 header 中添加非必要字段；若必须加，确保后端
Access-Control-Allow-Headers已同步更新 - 不要用
mode: 'no-cors'——这会让响应变成 opaque 类型，JS 完全无法读取状态码或 body，失去错误诊断能力
调试与验证方法
上线前务必验证实际请求链路：
- 打开浏览器 Network 面板，筛选
XHR或Fetch，查看上报请求是否有OPTIONS预检项 - 点击该 OPTIONS 请求，在 Response Headers 中确认是否存在全部必需的
Access-Control-Allow-*字段 - 再点主 POST 请求，检查 Response Headers 是否同样包含这些头（尤其是
Access-Control-Allow-Origin） - 用 curl 模拟预检：
curl -I -X OPTIONS -H "Origin: https://your-site.com" -H "Access-Control-Request-Method: POST" https://api.your-collect.com/track，观察返回头
