fetch是当前最可靠、最可控的HTML动态内容加载方式，适用于页眉、列表等结构化片段；需用DOMParser解析响应文本并提取body内容注入，避免innerHTML直接赋值导致脚本不执行或结构错乱。
fetch 是当前最可靠、最可控的 HTML 动态内容加载方式，其他方案要么受限（如 iframe 隔离上下文）、要么已废弃（如 HTMLImports）、要么不适用于结构化内容（如 document.write）。
用 fetch 加载外部 HTML 片段并注入 DOM
这是现代静态站点最常用的方案，适用于页眉、文章列表、表单步骤等可拆分的 HTML 内容。关键不是“能不能加”，而是“怎么加才不崩”：
- 外部 HTML 文件（如
header.html）必须只含片段，不能有、或重复，否则解析后结构错乱 - 不要直接赋值
innerHTML，尤其当内容含<script></script>时——它们不会自动执行；需手动提取并eval或appendChild脚本节点（但慎用eval） - 推荐用
DOMParser解析响应文本，再从doc.body取内容：const parser = new DOMParser();<br>const doc = parser.parseFromString(htmlText, 'text/html');<br>container.innerHTML = '';<br>container.appendChild(doc.body.firstElementChild);
- 加载失败时，
fetch不会 reject HTTP 404/500，得手动检查response.ok
iframe 加载完整 HTML 页面的适用边界
它不是“动态加载 HTML 内容”的通用解法，而是一种**隔离式页面切换**手段，适合老旧环境或强隔离需求：
- 优点：零 JS、兼容 IE11 和 Zebra 扫描终端浏览器、天然沙箱（
sandbox="allow-scripts allow-same-origin"可控放开权限） - 缺点：无法与父页面共享状态、
iframe内脚本无法直接操作外层 DOM、SEO 不友好、移动端滚动嵌套易卡顿 - 若要用，
src必须指向完整可访问的 HTML 文件路径（如pages/shipping.html），不能是相对路径拼错或跨域资源 - 别依赖
iframe.onload做逻辑触发——某些浏览器在缓存命中时可能不触发，改用contentWindow+postMessage更稳
避免用 document.write 或内联 innerHTML 拼接大块 HTML
这两种写法在真实项目中几乎等于埋雷：
-
document.write在页面加载完成后调用会清空整个文档，2026 年仍有不少遗留代码这么写，结果就是白屏 - 硬编码 HTML 字符串到 JS 中（如
el.innerHTML = '<div> <h3>' + title + '</h3>...'）极易引号嵌套错误、XSS 漏洞、调试困难，且无法利用浏览器对 HTML 文件的缓存 <li>如果内容含用户输入，必须做 <code>textContent替换或DOMPurify.sanitize()，不能无脑innerHTML - 多步骤向导类场景，优先拆成
stage1.html、stage2.html等独立文件，而非在 JS 里维护一长串模板字符串
真正难的不是“怎么把 HTML 放进去”，而是“放进去之后脚本能跑、样式不冲突、SEO 可抓取、错误能降级”。多数人卡在没处理好
DOMParser 解析后的脚本重执行，或忽略 response.redirected 导致 302 后取不到真实 HTML。
