html无原生标签，可行方案分三类：js动态加载（fetch+innerhtml，同源限制、seo差）、iframe嵌入（隔离强但交互/无障碍/seo受限）、构建时处理（webpack/vite/ssg等，推荐生产环境使用）。
HTML 本身没有原生的 <include></include> 标签，所以不能像 PHP 或 SSG 那样直接“引用外部 HTML 片段”。所有可行方案都依赖 JavaScript、服务端处理，或构建工具介入——纯静态 HTML + 原生标签做不到。
用 fetch() + innerHTML 动态加载（最常用）
这是现代前端最轻量、无需构建步骤的方案，适用于已知路径且允许 JS 执行的场景。
- 必须确保目标 HTML 片段是同源的（否则会触发 CORS 错误）
- 推荐把片段放在
/fragments/header.html这类路径下，避免放在根目录或敏感路径 - 加载后需手动插入到指定容器，且无法继承父页面的全局样式/脚本（除非显式重载）
- SEO 不友好：搜索引擎爬虫通常不执行 JS，因此不会索引这些动态内容
fetch('/fragments/footer.html')
.then(response => response.text())
.then(html => {
document.getElementById('footer-placeholder').innerHTML = html;
});
用 <iframe></iframe> 嵌入（简单但限制多）
它不是“引用片段”，而是嵌入一个独立文档上下文，适合隔离性强、内容稳定的小模块（如通知栏、广告位）。
-
<iframe src="/fragments/sidebar.html"></iframe>可以工作，但sidebar.html必须是完整 HTML 文档（含、） - 父页面和 iframe 内容默认无法通信（跨域时），样式和脚本完全隔离
- 移动端易出现滚动冲突、缩放异常；无障碍支持差；SEO 同样不收录 iframe 内容
- 不推荐用于导航栏、页脚等需要与主页面样式/交互联动的部分
构建时处理（推荐用于生产环境）
真正解决“引用 HTML 片段”需求的正解，是在构建阶段完成拼接，输出纯静态 HTML。这时浏览器看到的就是完整页面，无兼容性、SEO、性能问题。
动态WEB网站中的PHP和MySQL：直观的QuickPro指南第2版
下载
动态WEB网站中的PHP和MySQL详细反映实际程序的需求，仔细地探讨外部数据的验证(例如信用卡卡号的格式)、用户登录以及如何使用模板建立网页的标准外观。动态WEB网站中的PHP和MySQL的内容不仅仅是这些。书中还提到如何串联JavaScript与PHP让用户操作时更快、更方便。还有正确处理用户输入错误的方法，让网站看起来更专业。另外还引入大量来自PEAR外挂函数库的强大功能，对常用的、强大的包
立即学习“前端免费学习笔记（深入）”；
- Webpack 用户可用
html-webpack-plugin+html-loader，配合require('./header.html') - Vite 用户可用
vite-plugin-html或自定义插件读取并注入 - 若用 Hugo/Jekyll 等静态站点生成器，直接用原生 partial 语法：
{{ partial "header.html" . }} - 关键点：所有片段在部署前已合并，最终 HTML 中不存在“引用”逻辑
为什么 document.write() 和 <object></object> 应该避开
这两种方法在历史上曾被尝试，但现在存在明确缺陷，不建议新项目使用。
-
document.write()在页面加载完成后调用会清空整个文档，且无法异步控制，现代浏览器已标记为“deprecated” -
<object data="/fragments/alert.html"></object>虽能加载，但加载失败时显示空白或 fallback 内容不可靠；部分浏览器会阻止自动执行其中的<script></script>；iOS Safari 对<object></object>的data属性支持不稳定 - 两者都不支持传参、条件加载、错误重试等基本能力
真正要落地“引用 HTML 片段”，得先明确：这个页面是否允许 JS 执行？是否需要 SEO？是否要复用逻辑而非仅结构？选错路径会导致后期维护成本陡增——比如一开始用 fetch 加载页头，半年后发现 SEO 掉量严重，再切构建时方案就得重写整套模板流程。
