crossorigin="use-credentials"由浏览器自动携带Cookie等凭证，模块加载器不管理Token；服务端必须返回精确Origin域名和Access-Control-Allow-Credentials: true，缺一则加载失败。
模块加载器（如 Sea.js、Webpack 的动态 import()、或原生 ES 模块加载器）在处理 crossorigin="use-credentials" 时，本身不生成或管理 Token，它只负责按规范构造符合 CORS 凭据模式的请求。所谓“Token 传递”，本质是浏览器自动携带用户凭证（如 Cookie、HTTP 认证凭据），而非模块加载器主动注入或转发某个 Token 字符串。
浏览器才是凭证传递的执行者
当模块加载器触发一个跨域脚本加载（例如通过 import() 加载 CDN 上的 chunk），并配置了 crossOriginLoading: 'use-credentials'（Webpack）或显式写入 <script crossorigin="use-credentials" src="...">（Sea.js 手动配置）时：
- 浏览器会将该请求标记为 CORS 模式 + 凭据模式（
credentials: include） - 自动在请求头中添加
Origin和用户当前域的有效凭证（如同源 Cookie、已缓存的 HTTP Basic Auth 信息） - 不依赖模块加载器读取、解析或附加任何自定义 Token 字段
服务端必须严格响应匹配的 CORS 头
凭证能成功传递的前提，是服务端响应头满足两个硬性条件（缺一不可）：
-
Access-Control-Allow-Origin: https://your-app.com（必须是具体协议+域名，不能是 *） Access-Control-Allow-Credentials: true
若任一缺失，浏览器会在预检（OPTIONS）或主请求阶段直接拦截，控制台报错 Blocked by CORS policy，且模块加载失败——此时模块加载器无法“补救”，也收不到任何 JS 错误事件（因网络层已拒绝）。
与 Token 类机制（如 Bearer）的关键区别
注意：crossorigin="use-credentials" 不等价于手动在请求头加 Authorization: Bearer xxx：
- 它只启用浏览器内置的凭据自动携带机制（Cookie / HTTP Auth），不支持自定义 Token 字段
- 若你用的是 JWT 或 API Key，需由应用层在 fetch / axios 中显式传入，和
crossorigin无关 - 模块加载器（包括
import()）不提供钩子让你注入Authorization头；这类 Token 必须改用fetch()+eval（不推荐）或构建时内联等方式绕过 script 标签加载
常见配置陷阱
实际工程中容易踩坑的点：
- Webpack 设置
crossOriginLoading: 'use-credentials'，但 CDN（如 Nginx、OSS）未返回Access-Control-Allow-Credentials: true→ 加载静默失败 - CDN 返回了
Access-Control-Allow-Origin: *，却同时设了Access-Control-Allow-Credentials: true→ 浏览器直接报错（规范禁止两者共存） - 前端用了
withCredentials: true的fetch()请求资源，却误以为这会影响后续import()的凭证行为 → 两者完全独立，无继承关系
