根本原因是浏览器对 file:// 协议的跨源限制，必须通过 HTTP 服务（如 Live Server、http-server 或 Python 内置服务器）运行；路径需以 HTML 文件位置为基准，区分相对/绝对路径；GitHub Pages 等 Linux 环境严格区分大小写；动态导入和预加载路径须字面量精确；前端路由需服务端 fallback 配置。
本地双击打开 HTML 文件时，fetch 或 XMLHttpRequest 报错：CORS policy: No 'Access-Control-Allow-Origin' header
这不是 HTML5 的问题，而是浏览器的安全限制：当文件通过 file:// 协议直接打开（比如双击桌面的 index.html），所有跨文件读取（包括加载 .js、.json、.png 等外部资源）都会被阻止，哪怕它们在同一文件夹下。错误信息里出现 No 'Access-Control-Allow-Origin' 就是典型表现。
解决办法只有一个：不能双击运行，必须用 HTTP 服务打开。常见做法：
- 用 VS Code 安装
Live Server插件，右键 HTML 文件 →Open with Live Server - 命令行中进入项目目录，执行
npx http-server（需先npm install -g http-server），然后访问http://127.0.0.1:8080 - Python 用户可临时用
python3 -m http.server 8000（Python 3.7+ 自带）
引用外部 CSS/JS 时页面空白或功能失效，检查 src 和 href 路径是否写错
HTML5 本身不改变路径解析规则，但新手常混淆相对路径起点——它永远以「当前 HTML 文件所在位置」为基准，不是以代码编辑器打开的文件夹根目录为准。
假设结构如下：
立即学习“前端免费学习笔记（深入）”；
my-site/
├── index.html
├── js/
│ └── main.js
└── css/
└── style.css
那么 index.html 中正确引用是：
-
✅ -
✅ -
✅（./可省略） -
在my-site/subpage/about.html里就 ❌，应改为../js/main.js
绝对路径（以 / 开头）则从网站根目录算起，只在部署到真实服务器（如 Nginx/Apache）且配置了正确根路径时才稳定可用。
部署到 GitHub Pages 后图片/字体/接口全部 404，检查大小写和扩展名是否匹配
GitHub Pages 运行在 Linux 服务器上，而 Linux 文件系统严格区分大小写；Windows 本地开发时可能不报错，一上传就失效。
典型翻车点：
- 本地写
img/logo.png→ 404 - 引用
font.woff2，但文件后缀是.WOFF2或.woff2?（多了一个问号）→ 404 - JSON 接口地址写成
/API/data.json，但后端路由是/api/data.json→ 404 + CORS
建议：本地开发时就用大小写敏感的环境测试（如 WSL 或 Docker），或统一用小写命名所有资源文件和路径段。
使用 import() 动态导入时，路径在发布后失效
这两个特性对路径更敏感，因为它们不经过 HTML 解析器的常规路径修正逻辑。
例如：
-
→ 必须确保data/config.json真实存在且大小写完全一致 -
const mod = await import('./utils/helpers.js');→ Webpack/Vite 会处理，但原生 ES 模块要求路径字面量精确，不能拼字符串 - 动态 import 中若用变量拼路径（如
import('./mods/' + name + '.js')），构建工具通常无法静态分析，发布后大概率报Failed to fetch dynamically imported module
真正可靠的动态加载，要么用构建工具预定义模块映射，要么改用 fetch + eval（不推荐）或后端兜底路由。
最易被忽略的一点：很多“发布成功”的网页其实只是首页能打开，但深层路由（如 /about）刷新就 404——这说明你没配服务端的 fallback，或者用了前端路由却没启用 history.pushState 兼容模式。这个问题不在 HTML5 规范里，但在真实发布中几乎必踩。
