最推荐 fetch + innerHTML 方案，兼容性好且可控性强；iframe 最简单但问题多，仅限原型或隔离场景；服务端 include 或构建时预处理才是真正的引用解法；HTML Modules 仍属实验性不可用于生产。
iframe 是最简单但最不推荐的引用方式
直接用 <iframe></iframe> 嵌入另一个 html 文件，浏览器能立刻渲染，但会带来一堆隐性问题：父页面滚动条可能失控、document.title 和 history.pushstate 不同步、seo 几乎为零、移动端手势（比如双指缩放）容易冲突。
常见错误现象：iframe 高度固定导致内容被截断、父页面点击事件无法穿透、加载后 JS 作用域隔离导致调用失败。
- 只在原型演示或完全隔离的嵌入场景（如第三方 widget）中考虑它
- 务必设置
sandbox属性限制权限，避免安全风险 - 如果必须用，用 JS 动态计算
iframe内容高度并同步设置height样式
fetch + innerHTML 是现代前端最常用的动态加载方案
用 fetch() 请求目标 HTML 文件，拿到字符串后插入到指定容器里，再手动执行其中的 <script></script> 标签——这是目前兼容性好、可控性强的主流做法。
使用场景：单页应用中局部刷新、CMS 系统中模块化内容区块、需要复用头部/侧边栏但又不想服务端渲染的项目。
-
fetch('header.html')返回的是纯文本，不能直接append()，得先用innerHTML = responseText - 原 HTML 中的
<script></script>不会自动执行，需提取并用eval()或创建新<script></script>标签注入（注意 CSP 限制） - 相对路径在子 HTML 中会以当前页面 URL 为基准解析，不是以被加载文件位置为准
服务器端 include 或构建时预处理才是真正“引用”的解法
浏览器本身不支持原生 HTML 文件间引用，所谓“引用”本质是服务端拼接或构建工具提前合并。想让 index.html “包含” nav.html，必须靠外部介入。
一个功能强大的B2B与B2C的购物平台，除了原本OSC功能外，增加更新的功能： 一、 取消了register_globals必须开启的限制 二、 將HTML程式碼与PHP程式碼完全分离，採用了smarty 樣板引擎 三、 每支档案includes所需函数与资料库连结，使的网页显示速度明显提升 四、 检视、购买商品群组权限设定 五、 十八岁以下禁购机制 六、 折价券购物抵扣机制 七、 礼券购物机制
立即学习“前端免费学习笔记（深入）”；
参数差异：Nginx 的 include 指令要求文件在同一目录且无缓存干扰；Webpack 的 html-webpack-plugin + html-loader 支持 这类写法；PHP 则直接 include 'nav.html';。
- Node.js 开发常用
express.static配合中间件做运行时 include，但性能不如构建时处理 - 静态站点生成器（如 Hugo、Jekyll）把 include 当核心功能，语法更自然，但脱离构建流程就失效
- 注意文件编码统一为 UTF-8，否则
include后出现乱码几乎不可避免
import map + HTML Modules（实验性）目前基本不能用
Chrome 120+ 支持通过 <script type="importmap"></script> 声明模块映射，再用 import 加载 HTML 文件作为模块，但这是 HTML Modules 提案的一部分，尚未标准化，Firefox/Safari 完全不支持。
错误信息示例：Failed to resolve module specifier "nav.html". Relative references must start with either "/", "./", or "../". 就是因为没配 import map 或路径不合法。
- 即使开启实验标志，
import './nav.html' assert { type: 'text/html' }返回的是Response对象，仍需手动解析 - 当前阶段仅适合技术验证，别放进生产环境
- 依赖构建工具（如 Vite 插件）才能模拟类似行为，本质还是 fetch + 注入
