XMLHttpRequest 和 fetch 在 file:// 协议下必然失败，因浏览器将 file:// 视为不同源且强制拦截，无法关闭；唯一可靠解法是启用本地 HTTP 服务（如 Live Server、python3 -m http.server），使页面运行在 http:// 下。
HTML5 中的 XMLHttpRequest（或 fetch）在本地直接打开 HTML 文件（file:// 协议）时被拦截，不是 bug，是浏览器的强制安全策略，无法“关闭”——所谓“关闭浏览器安全限制”本质上不可行，也不应尝试。
为什么 file:// 下的 XMLHttpRequest 一定失败
所有现代浏览器（Chrome、Edge、Firefox、Safari）都将 file:// 协议视作不同源（origin），且默认禁止其发起跨源请求。即使目标是同目录下的 data.json，XMLHttpRequest 也会被拒绝，控制台报错类似：
Access to XMLHttpRequest at 'file:///path/to/data.json' from origin 'null' has been blocked by CORS policy.
这个行为由标准规定，与是否勾选“允许本地文件访问”无关（Chrome 的 --unsafely-treat-insecure-origin-as-secure 等启动参数仅影响特定 insecure origin 的权限提升，不适用于 file://）。
真正可行的替代方案：用本地 HTTP 服务代替 file://
绕过拦截的唯一可靠方式，是让页面运行在 http:// 或 https:// 协议下。无需部署服务器，几条命令就能起一个最小服务：
立即学习“前端免费学习笔记（深入）”；
- VS Code 用户：安装插件
Live Server，右键 HTML 文件 → “Open with Live Server”，自动打开http://127.0.0.1:5500/xxx.html - Python 3 用户（已安装）：
python3 -m http.server 8000
然后访问http://localhost:8000/your-page.html - Node.js 用户：
npx http-server -p 8080
（需先npm install -g http-server）
此时 XMLHttpRequest 和 fetch 均可正常读取同域下的本地 JSON、XML 文件，无任何额外配置。
哪些“禁用安全限制”的操作是无效甚至危险的
网上常见误导方案，实际无效或已被废弃：
- Chrome 启动加
--disable-web-security：自 Chrome 94 起完全失效；即使旧版本生效，也会禁用全部安全机制（如 XSS 过滤、混合内容拦截），极大增加风险 - 修改系统 hosts 或注册伪域名指向本地：仍无法绕过
file://协议的 origin 限制 - 用 Electron / WebView 打包：属于换技术栈，不是“关闭浏览器限制”，且引入新复杂度
试图从浏览器层面“解除限制”，等于要求浏览器放弃最基本的安全边界，这既不现实，也违背设计初衷。
本质问题从来不是“怎么关限制”，而是“怎么让开发环境符合浏览器安全模型”。用一行命令起个本地 HTTP 服务，是最小改动、最大兼容的解法。别碰启动参数，别信“禁用安全”的教程，把文件放进 http:// 下，问题自然消失。
