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://)。
file://
绕过拦截的唯一可靠方式,是让页面运行在 http:// 或 https:// 协议下。无需部署服务器,几条命令就能起一个最小服务:
立即学习“前端免费学习笔记(深入)”;
Live Server,右键 HTML 文件 → “Open with Live Server”,自动打开 http://127.0.0.1:5500/xxx.html
python3 -m http.server 8000然后访问
http://localhost:8000/your-page.html
npx http-server -p 8080(需先
npm install -g http-server)此时 XMLHttpRequest 和 fetch 均可正常读取同域下的本地 JSON、XML 文件,无任何额外配置。
哪些“禁用安全限制”的操作是无效甚至危险的网上常见误导方案,实际无效或已被废弃:
--disable-web-security:自 Chrome 94 起完全失效;即使旧版本生效,也会禁用全部安全机制(如 XSS 过滤、混合内容拦截),极大增加风险file:// 协议的 origin 限制试图从浏览器层面“解除限制”,等于要求浏览器放弃最基本的安全边界,这既不现实,也违背设计初衷。
本质问题从来不是“怎么关限制”,而是“怎么让开发环境符合浏览器安全模型”。用一行命令起个本地 HTTP 服务,是最小改动、最大兼容的解法。别碰启动参数,别信“禁用安全”的教程,把文件放进 http:// 下,问题自然消失。