Live Server 本身不添加 CORS 响应头，仅将 file:// 转为 http://127.0.0.1:5500 以绕过本地文件限制；跨域请求需通过 proxy 配置转发（如 .vscode/settings.json 中设置 proxyUrl 和 proxyPrefix），或由后端显式配置 CORS。
Live Server 启动后 fetch 报 No 'Access-Control-Allow-Origin'
这不是 Live Server 的 bug，也不是你代码写错了——它压根没在服务端加任何 CORS 响应头。Live Server 只是把 file:// 换成 http://127.0.0.1:5500，绕过浏览器对本地文件的限制，但对跨域请求不作处理。
常见错误现象：
- 前端页面跑在
http://127.0.0.1:5500，fetch 请求发到http://localhost:3000/api，报错 - 用
fetch("/api/data")直接相对路径，结果请求发到了http://127.0.0.1:5500/api/data（404），误以为是跨域
正确做法是配代理，不是改前端 URL：
- 在 VSCode 工作区根目录创建
.vscode/settings.json - 加这段配置（以代理
/api到后端为例）：{ "liveServer.settings.proxy": { "enable": true, "proxyUrl": "http://localhost:3000", "proxyPrefix": "/api" } } - 重启 Live Server，之后所有
/api/xxx请求会自动转发到http://localhost:3000/api/xxx，浏览器看到的是同源请求
注意：Live Server 的 proxy 不支持通配、重写或动态 origin，只做前缀匹配；如果后端接口路径不统一，得手动拆多个 proxyPrefix 条目。
Chrome 调试时加 --disable-web-security 为什么无效
VSCode 的 launch.json 里加了 "--disable-web-security" 却仍被拦截，大概率是因为 Chrome 实例没真正用上这个参数——它可能复用了已存在的用户数据目录，而该目录下已有运行中的 Chrome 进程。
关键点：
-
--disable-web-security必须配合--user-data-dir使用，否则 Chrome 会拒绝启动（或降级为普通模式） - 不能和已有 Chrome 窗口共用 profile，否则参数被忽略
- Windows/macOS/Linux 对空格、路径转义敏感，
runtimeArgs中路径含空格必须用引号包裹
推荐配置（确保干净启动）：
{
"type": "chrome",
"request": "launch",
"name": "Launch Chrome (no security)",
"url": "http://localhost:5500",
"webRoot": "${workspaceFolder}",
"runtimeArgs": [
"--disable-web-security",
"--user-data-dir=/tmp/chrome-dev-session"
]
}
Linux/macOS 用户注意：/tmp/chrome-dev-session 需有写权限；Windows 可改用 C:\temp\chrome-dev。每次调试完记得删掉该目录，避免残留影响下次。
用 code --disable-extensions 排查插件引发的 CORS 类报错
某些插件（比如旧版 ms-python.python 或带网络拦截逻辑的 AI 补全工具）会在启动阶段注入 HTTP 客户端钩子，偷偷修改 fetch / XMLHttpRequest 行为，导致请求头异常、origin 被篡改、甚至直接拦截响应。
这类问题不会报明确插件名，只在控制台显示：
-
Failed to fetch但 Network 面板看不到请求发出 - Response headers 里缺
Access-Control-Allow-Origin，但后端确认已配置 - 同一份代码，在安全模式下正常，开插件后必现
排查步骤：
- 终端执行
code --disable-extensions（不带任何路径参数），打开空窗口 → 手动拖入 HTML 文件测试 - 若此时正常，说明是插件干扰；再用
code --disable-extension esbenp.prettier-vscode逐个排除高频嫌疑插件 - 重点盯
Developer: Open Extension Host Log，搜索fetch、XMLHttpRequest、intercept等关键词
特别提醒：Prettier、ESLint、Tailwind CSS 插件本身不碰网络，但它们依赖的底层语言服务器（如 tailwindcss-language-server）可能因配置错误发起跨域请求并失败，日志藏在 exthost 进程里，不在 UI 显示。
Socket.io 连接报 CORS 却死活配不好
Socket.io 的 CORS 和普通 HTTP 完全不是一回事。你在 Express 里加了 app.use(cors())，对 Socket.io 握手请求毫无作用——它根本收不到那个中间件。
必须在初始化 Server 实例时显式传 cors 选项：
- origin 不能写
*，尤其当客户端带withCredentials: true时，浏览器直接拒收响应 - 如果前端用 Live Server（
http://127.0.0.1:5500），后端必须写origin: "http://127.0.0.1:5500"，写localhost或漏协议都会失败 - Live Server 无法代理 WebSocket，所以别指望它转发
/socket.io/路径——那是徒劳
最小验证配置（Node.js）：
const { createServer } = require('http');
const { Server } = require('socket.io');
const httpServer = createServer();
const io = new Server(httpServer, {
cors: {
origin: "http://127.0.0.1:5500",
methods: ["GET", "POST"],
credentials: true
}
});
io.on('connection', (socket) => console.log('connected'));
httpServer.listen(4000);
最后检查浏览器 Network 面板：找 /socket.io/?EIO= 请求，看 Request Headers 里的 Origin 是否和你配置的 origin 完全一致——差一个斜杠、大小写、端口，都算跨域失败。
