浏览器的JavaScript运行环境（如fetch、XMLHttpRequest）和部分HTML特性（如<canvas>）执行同源策略，而非HTML本身；服务端需配置CORS响应头（如Access-Control-Allow-Origin）才能合法允许跨域请求。
HTML 本身不执行同源策略，真正 enforce 同源策略的是浏览器的 JavaScript 运行环境（如 fetch、XMLHttpRequest、iframe.contentWindow）和部分 HTML 特性（如 <canvas> 读取跨域图片后调用 toDataURL()）。所谓“HTML 跨域不支持同源策略”，其实是误解了责任主体——你没法绕过浏览器的安全模型，但可以合法地让跨域请求被接受。
为什么 fetch 或 XMLHttpRequest 直接请求其他域名会报 CORS 错误
这不是 HTML 的限制，而是浏览器在发起跨域资源请求时，自动检查目标服务器是否明确允许当前源（Origin）访问。如果响应头里没有 Access-Control-Allow-Origin，或值不匹配，就会拦截响应体（即使 HTTP 状态码是 200）。
- 常见错误现象：
Failed to fetch: No 'Access-Control-Allow-Origin' header is present - 注意：预检请求（OPTIONS）失败时，控制台可能只显示
net::ERR_FAILED，需看 Network 面板的 OPTIONS 请求详情 - 前端无法单靠改 HTML 或 JS 绕过——服务端必须配合返回正确的 CORS 头
- 例外：某些请求是“简单请求”（GET/POST + 纯文本 Content-Type + 有限 headers），可跳过预检；但一旦带
Authorization或自定义 header，就一定触发 OPTIONS
如何让前端发跨域请求不被浏览器拦截（服务端要做什么）
关键不是前端“提升同源策略”，而是服务端主动声明信任关系。不同后端框架写法不同，但核心都是设置响应头：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
Access-Control-Allow-Origin: https://your-frontend.com（生产环境禁止用*，尤其带 credentials 时） -
Access-Control-Allow-Credentials: true（若前端fetch带了credentials: 'include'，则此头必须存在且值为true，且Allow-Origin不能为*） -
Access-Control-Allow-Headers：列出前端实际发送的非简单 header，比如Authorization, X-Requested-With -
Access-Control-Allow-Methods：明确允许的 HTTP 方法，如GET, POST, PUT, DELETE - Node.js Express 示例：
app.use((req, res, next) => { res.header('Access-Control-Allow-Origin', 'https://your-frontend.com'); res.header('Access-Control-Allow-Credentials', 'true'); res.header('Access-Control-Allow-Headers', 'Authorization, X-Requested-With'); res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE'); next(); });
开发阶段快速绕过 CORS（仅限本地调试，不可用于生产）
浏览器安全策略不能被网页代码关闭，但你可以临时让浏览器不校验——本质是绕过，不是解决。
立即学习“前端免费学习笔记（深入）”；
- Chrome 启动时加参数：
chrome --user-data-dir="/tmp/chrome_dev" --disable-web-security（注意：必须指定独立--user-data-dir，否则会警告并拒绝启动） - 使用代理：Webpack Dev Server、Vite、Vue CLI 都支持
proxy配置，把/api/代理到后端地址，使前端请求看起来是同源的 - Vite 示例：
server: { proxy: { '/api': { target: 'http://localhost:3000', changeOrigin: true, rewrite: (path) => path.replace(/^\/api/, '') } } } - 注意：这些方法对
iframe加载跨域页面、<img>的跨域加载等场景无效——它们走的是不同安全路径（如 COEP/COOP 或 referrer policy）
真正难的不是加几个响应头，而是理解哪些资源受哪条规则约束：CORS 控制脚本数据读取，COEP 控制跨域 iframe 资源加载，crossorigin 属性决定是否触发 CORS 检查……混用时容易漏掉一环。
