同源策略默认强制生效，无法关闭；跨域需通过CORS等合法手段实现，其中服务端决定能否响应，浏览器决定能否接收，前端配置mode: 'cors'仅触发流程而非授权。
同源策略不是“选不选”的问题，它默认强制生效
浏览器根本不会给你“关闭同源策略”的开关——这是安全底线。所谓“HTML跨域关联”，实际是绕过限制的合法手段，不是关闭策略本身。新手常误以为加个 crossorigin 属性或改个响应头就能自由跨域，结果发现 fetch 仍被拦、XMLHttpRequest 报 TypeError: Failed to fetch，本质是没搞清谁在控制权限：服务端决定“能不能给”，浏览器决定“敢不敢拿”。
CORS 配置必须由后端设置，前端加 mode: 'cors' 不会起作用
前端发起请求时写 fetch(url, { mode: 'cors' })，只是告诉浏览器：“我要走 CORS 流程”，但能否成功完全取决于目标服务器是否返回了合法的响应头，比如：Access-Control-Allow-Origin: https://your-site.com 或 Access-Control-Allow-Credentials: true（如果带 cookie）。常见错误包括：
- 后端只配了
Access-Control-Allow-Origin: *，但前端又传了credentials: 'include'—— 这直接失败，因为*和凭据不兼容 - 本地开发用
file://协议打开 HTML，此时没有 origin，CORS 请求一律被拒（连预检都发不出） - 用了 Nginx 反向代理却忘了透传 CORS 头，导致前端看到的是代理层返回的默认响应，而非真实 API 的头
JSONP 已淘汰，别再为跨域硬塞 <script> 标签
JSONP 利用 <script> 标签不受同源限制的特性，但它只支持 GET，无法设 header、无错误捕获、依赖服务端配合回调函数名，且现代浏览器已逐步限制非同源 script 的执行上下文。现在遇到跨域，优先走标准 CORS；若后端完全不可控（如调第三方老接口），可考虑代理中转，而不是手写 callback=xxx 拼 URL。更现实的替代是：postMessage（用于 iframe 跨域通信）、Service Worker 拦截并改写响应（需 HTTPS）、或用后端做一层轻量代理。
document.domain 仅适用于子域名通信，且现代 Chrome 已限制其使用范围
过去用 document.domain = 'example.com' 让 a.example.com 和 b.example.com 下的 iframe 互相访问 DOM，但现在 Chrome 要求两个页面都显式设置相同值，且协议、端口也必须一致；更关键的是，只要任一页面启用了 Content-Security-Policy 或加载了 module script，document.domain 就会被锁定不可写。所以除非你明确控制所有子域页面且不涉及现代特性，否则这条路基本走不通。
立即学习“前端免费学习笔记（深入）”；
真正卡住新手的，往往不是“怎么配 CORS”，而是分不清请求发起方（前端）、响应提供方（后端）、中间环节（代理/Nginx）各自该承担什么责任。一个跨域请求失败，先看 Network 面板里预检请求（OPTIONS）有没有 200，再看主请求的 Response Headers 里有没有合法的 Access-Control-Allow-*，最后确认前端代码没在不该带凭据的时候带了 credentials。
