crossorigin="use-credentials"仅表示允许携带凭据，是否真发Cookie取决于服务端响应头（Access-Control-Allow-Origin需为具体域名且含Access-Control-Allow-Credentials: true）、Cookie自身属性（如SameSite=None; Secure）及上下文环境。
crossorigin="use-credentials" 本身不会自动带 Cookie
很多人以为只要写了 crossorigin="use-credentials"，浏览器就会像普通页面请求一样自动带上 Cookie —— 这是错的。它只表示“允许携带凭据”，但是否真发 Cookie，取决于服务端响应头和当前上下文。
关键点有三个：
- 脚本必须是同源或服务端明确允许凭据：响应头必须包含
Access-Control-Allow-Origin（不能是*），且必须有Access-Control-Allow-Credentials: true - Cookie 本身得满足
SameSite和Secure要求：比如在 HTTPS 环境下，SameSite=None; Secure才可能被第三方上下文携带 -
<script>标签需显式声明：<script crossorigin="use-credentials" src="https://api.example.com/script.js"></script>，缺crossorigin属性，即使 Cookie 符合条件也不会发
为什么 script 加载时 Cookie 经常被忽略
常见错误场景：
- 服务端返回
Access-Control-Allow-Origin: *→ 浏览器直接拒绝凭据，无视crossorigin="use-credentials" - Cookie 缺少
Secure，但页面走 HTTPS → Chrome/Firefox 拒绝发送 - Cookie 的
Domain设置错误，比如设成example.com，但请求来自app.example.com→ 不匹配就不带 - 脚本加载发生在 iframe 或 sandboxed 上下文中，且没加
allow-scripts allow-same-origin→ 凭据被隔离
验证 Cookie 是否真的发出：用 DevTools Network 面板看 Request Headers
别猜，直接看：
立即学习“前端免费学习笔记（深入）”；
- 在 Network 面板中找到那个
script请求，点开 → 查看Request Headers区域 - 确认有没有
Cookie:行；没有就说明没发出去 - 再看
Response Headers：必须同时存在Access-Control-Allow-Origin: https://your-site.com和Access-Control-Allow-Credentials: true - 如果看到
Failed to load resource: Origin ... is not allowed by Access-Control-Allow-Origin错误 → 服务端 CORS 配置没配对
替代方案：动态 fetch + eval（慎用）
当无法控制服务端响应头，又必须带 Cookie 加载远程脚本时，有人会用 fetch 手动取脚本内容再 eval。但要注意：
-
fetch(url, { credentials: 'include' })能正常带 Cookie，前提是服务端 CORS 允许（同上要求） -
eval执行有 CSP 风险：若页面启用了script-src 'self'，eval会被拦截，报Refused to evaluate a string as JavaScript - 执行上下文丢失：
eval内部的this是全局对象，但模块变量、import、export都不支持 —— 只适合纯函数式、无依赖的脚本
真正要加载模块化脚本，还是得靠服务端配合，或者改用 <script type="module"> + 正确的 CORS 响应头。
最常被忽略的是：服务端必须把 Access-Control-Allow-Origin 设为具体域名，而不是通配符；哪怕只差一个协议（http vs https）或端口，浏览器都会判定不匹配，拒发 Cookie。
