掌握js跨域与cors最有效方式是本地搭建vite前端（http://localhost:5173）与express后端（http://localhost:3000）双服务，手动触发简单get、带自定义头的post（触发options预检）、带credentials的请求，逐层配置access-control-allow-origin/methods/headers/credentials响应头并实时观测network面板验证全流程。
直接在本地跑通一个能验证跨域行为、区分简单/复杂请求、并完整走通 CORS 流程的最小闭环项目，是掌握 JS 跨域与 CORS 的最有效方式。关键不在于堆功能，而在于把浏览器拦截、预检、响应头校验、凭证传递这些环节都“看得见、改得着、测得到”。
搭建双服务本地环境：前端页面 + 后端 API
这是所有演练的基础。不需要部署，全部本地启动：
- 前端：用 Vite 创建一个空项目，起在
http://localhost:5173，页面里只放一个按钮和一段fetch调用代码 - 后端：用 Express 写一个极简服务，监听
http://localhost:3000，提供一个/api/data接口，返回 JSON - 确保两者端口不同——这样浏览器一发起请求，就立刻触发跨域拦截，错误清晰可见
手动触发并观察三种典型请求行为
在前端代码中依次尝试以下三类调用，每执行一次都打开 Chrome 的 Network 面板看真实网络流：
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 请求：
fetch('http://localhost:3000/api/data')—— 看是否被拦；若后端未设Access-Control-Allow-Origin，会报错且无响应内容 -
带自定义 Header 的 POST：
fetch('http://localhost:3000/api/data', { method: 'POST', headers: { 'X-Trace-ID': 'abc123' } })—— 浏览器会先发一个OPTIONS预检请求；若后端没处理 OPTIONS 或没返回正确头，预检失败，主请求根本不会发出 -
带 Cookie 的请求：
fetch('http://localhost:3000/api/data', { credentials: 'include' })—— 此时后端必须返回Access-Control-Allow-Origin具体域名（不能是*），否则即使有响应，浏览器也会拒绝读取
后端逐层配置 CORS 响应头并验证效果
在 Express 中不依赖 cors 中间件，而是手动设置响应头，边配边测：
- 第一步：只加
res.header('Access-Control-Allow-Origin', 'http://localhost:5173')→ 解决基础 GET 跨域 - 第二步：再加
res.header('Access-Control-Allow-Methods', 'GET, POST, OPTIONS')和res.header('Access-Control-Allow-Headers', 'X-Trace-ID')→ 让带自定义头的 POST 通过预检 - 第三步：加
res.header('Access-Control-Allow-Credentials', 'true')→ 支持credentials: 'include'，同时确认 Origin 不能为* - 每加一行，重启后端，刷新前端页面重试，观察 Network 中响应头是否出现、预检是否成功、主请求是否拿到数据
用 curl 和浏览器对比，理解“CORS 是浏览器机制”
在终端执行：curl -H "Origin: http://localhost:5173" http://localhost:3000/api/data，你会发现它总能拿到响应，哪怕后端完全没配 CORS 头。这说明：
- CORS 拦截只发生在浏览器中，是浏览器单方面行为
- 后端返回什么头，浏览器才检查什么；后端不返回，浏览器就按默认规则拒绝
- Node.js、Python、curl 这些非浏览器客户端，根本不看也不管 CORS 头
