同源策略是跨域起点，cors是浏览器与服务端协商机制，后端配cors最标准，开发期代理仅限调试，排查需结合network与console报错反推。

直接画一张清晰、可落地的 JS 跨域与 CORS 思维导图，关键不是堆概念，而是抓住“浏览器拦什么、为什么拦、服务端怎么放行、前端怎么配合”这条主线。下面按实际开发中最常卡壳的四个模块来组织，每个模块都对应导图里的一个主分支，内容可直接转成节点。

一、同源策略：跨域的起点和边界

这是所有问题的源头，必须放在最顶层。

• 同源三要素：协议（http/https）、域名（a.com ≠ b.com）、端口（8080 ≠ 3000），三者完全一致才算同源
• 它只限制 JS 读取响应——请求发出去了，服务器也收到了，但浏览器把返回结果扣下了
• 不拦截的例外：<img>、<script></script>、<link> 可跨域加载资源，但 JS 拿不到它们的响应体（比如不能读取图片的二进制数据）

二、CORS 机制：浏览器和服务端的“暗号协议”

CORS 不是前端加个配置就能好，它是浏览器和服务端共同参与的一套协商流程。

wechat-article-extraction-mp-weixin-qq-com news-webpage-cleaning blog-post-parsing metadata-extraction-title-author-date multiple-output-formats-markdown-json-plain-text batch-processing-support

基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。

下载

• 简单请求（GET/HEAD/POST + 标准头如 Accept、Content-Type）：浏览器自动加 Origin 头，服务端必须返回 Access-Control-Allow-Origin，否则 JS 拿不到响应
• 非简单请求（PUT、DELETE、带自定义头如 Authorization）：先发一次 OPTIONS 预检，服务端要返回允许的方法、头、是否带凭证等，预检通过后才发真实请求
• 关键响应头不能漏：Access-Control-Allow-Origin（生产环境别用 *）、Access-Control-Allow-Credentials（设为 true 时 Origin 不能是 *）、Access-Control-Allow-Headers（列全前端传的自定义头）

三、常见解决方案对应导图分支

每个方案背后都有明确的适用场景和代价，导图里建议用“适用场景 + 注意点”双标签形式呈现。

• 后端配 CORS：最标准做法。Node.js 用 cors 中间件；.NET Core 用 AddCors；Nginx 加 add_header。注意动态 Origin 判断逻辑，避免硬写死域名
• 开发期代理（如 vite.config.ts 的 proxy）：前端启动时把 /api 代理到后端地址，让请求看起来是同源的。只用于本地调试，上线无效
• JSONP（已淘汰）：仅支持 GET，靠 <script></script> 标签绕过限制，无错误捕获、无状态管理，新项目别用
• 禁用浏览器安全（--disable-web-security）：纯临时排查手段，会彻底关闭同源保护，访问任何网站都不安全

四、排查思路：从控制台报错反推问题在哪

导图末尾建议加一个“故障树”式分支，帮人快速定位。

• 看 Network 面板：有没有 OPTIONS 请求？有没有 4xx/5xx 状态码？响应头里有没有缺失的 CORS 头？
• 看 Console 报错原文：提示 “No 'Access-Control-Allow-Origin' header” → 后端没配或配错了 Origin；提示 “Credentials flag is true” → 前端 fetch 里写了 credentials: 'include'，但后端没返回 Access-Control-Allow-Credentials: true 且 Access-Control-Allow-Origin 是具体域名
• 确认 Cookie 是否需要携带：需要就前后端都要开 credentials；不需要就前端 fetch 里去掉 credentials，后端也不用配相关头