Live Server仅将file://转为http://127.0.0.1:5500以绕过本地限制，不添加CORS响应头；跨域请求需通过.vscode/settings.json配置proxy代理，或改用Vite/Express等支持代理的开发服务器。
VSCode 里直接双击或用普通插件打开 HTML 文件，只要涉及 fetch、XMLHttpRequest、import 或视频/字体等资源加载，就大概率触发跨域报错——这不是你代码写错了，是浏览器根本没让你发请求。
Live Server 启动后 fetch 报 No 'Access-Control-Allow-Origin'
这是最常被误解的点：Live Server 压根不处理 CORS，它只做一件事——把 file:// 换成 http://127.0.0.1:5500。所以：
- 如果你的
fetch("/api/data")请求目标是http://localhost:3000/api/data，那浏览器看到的就是跨源请求，直接拦截，Network 面板里状态可能是(blocked:cors)或压根没发出 - 如果你的
fetch("/api/data")实际发到了http://127.0.0.1:5500/api/data（404），那是路径写错了，不是跨域问题 - Live Server 的代理功能只支持前缀匹配，比如配了
"proxyPrefix":"/api"，那/api/users会转，但/v1/users不会自动转
在 .vscode/settings.json 中配 proxy 失效的常见原因
Live Server 的代理必须靠 .vscode/settings.json 生效，但配置错一个地方就白搭：
- 文件必须放在工作区根目录（即你通过
File → Open Folder打开的那个文件夹），不能放在子目录或用户级设置里 -
"liveServer.settings.proxy"是顶层键，不是嵌套在其他配置下；漏掉"enable": true就不会启动代理 - 路径大小写敏感，Windows 上
C:\myproject和c:\myproject可能被识别为不同路径 - 改完配置后必须重启 Live Server（右下角点「Go Live」按钮再点一次，或关掉再开）
Chrome 调试时加 --disable-web-security 仍被拦截
这个参数单独加没用，Chrome 会忽略它，除非同时满足两个条件：
立即学习“前端免费学习笔记（深入）”；
-
--disable-web-security必须和--user-data-dir成对出现，且--user-data-dir指向一个**干净、空的、有写权限的目录**（比如/tmp/chrome-dev或C:\temp\chrome-dev） - 不能复用已有 Chrome 窗口或用户配置，否则参数被静默丢弃；Linux/macOS 注意路径权限，Windows 注意反斜杠和空格是否加引号
- VSCode 的
launch.json中若用了"type": "chrome"，runtimeArgs数组里必须完整写出这两个参数，顺序无关，但缺一不可
更稳的替代方案：换 dev server 而不是硬刚跨域
Live Server 适合纯静态页，一旦要连后端 API，它就力不从心。真正省事的做法是绕过跨域检查本身：
- 用 Vite 启服务：装
vite，建vite.config.js，配server.proxy，npm run dev启动后所有/api/xxx请求自动转发到http://localhost:3000 - 用 Express 托管前端：写个最小
app.js，app.use(express.static("."))，再加app.use("/api", proxy(...))，让页面和接口同源 - 别把
index.html当入口去“运行”，而是把它当成静态资源交给一个能配代理的服务器来 serve
跨域限制的本质是浏览器行为，不是 VSCode 或代码的问题。想临时跳过，得确保 Chrome 启动参数干净；想长期开发，就得让请求看起来是同源的——代理配置只是手段，核心是控制请求发起的 origin 和目标 endpoint 的关系。
