HTML模块复用需在构建期介入，用posthtml-include等工具将header.html等片段内联为标准HTML，避免fetch动态注入导致的样式丢失、脚本不执行及SEO问题。
用 include 类机制做静态 HTML 模块拆分
纯静态 HTML 项目没有服务端渲染能力，但依然可以通过构建时预处理实现模块复用。关键不是“能不能用”，而是“在哪一环介入”。posthtml-include 或 html-loader（Webpack）这类工具在打包阶段就把 header.html、footer.html 等片段内联进目标文件，最终输出的是标准 HTML，无运行时依赖。
常见错误现象：fetch() 动态加载 HTML 片段后直接 innerHTML 插入，结果样式丢失、脚本不执行、SEO 不友好——这本质是把构建期问题拖到了运行时。
- 确保所有 partial 文件路径相对于入口 HTML（如
pages/about.html引用partials/nav.html时，路径需按构建配置对齐） - 避免在 partial 中写
<script></script>标签；如需行为，统一由主页面 JS 控制 - 使用
posthtml-include时，语法是<include src="partials/header.html"></include>，不是注释或自定义标签
用 nav-loader.js 动态注入导航栏的边界条件
这是纯前端静态站最常用的“伪复用”手段：用 JS 抓取一个 HTML 字符串，再塞进 document.getElementById('nav').innerHTML。它能快速统一导航，但有明确限制。
容易踩的坑：nav-loader.js 在 DOM 加载前执行，导致 getElementById 找不到容器；或多个页面共用同一份 JS，但 id 冲突（比如两个 nav 容器都叫 nav）。
立即学习“前端免费学习笔记（深入）”；
- 必须包裹在
document.addEventListener('DOMContentLoaded', ...)或$(document).ready(...)中 - 注入目标元素的
id必须全局唯一，建议加前缀如js-nav-inject - 如果导航含交互（如下拉菜单），JS 初始化逻辑不能放在 partial 文件里，得在主 JS 中统一绑定
Web Components 不是“高级可选”，而是封装隔离刚需
当你需要一个带样式、逻辑、可复用的按钮或卡片组件，且不希望它的 CSS 泄露到全局，customElements.define() 是目前唯一原生解法。Shadow DOM 天然隔离，不是靠命名约定或 BEM 规范能替代的。
性能影响常被低估：每个 <my-button> 实例都会创建独立 Shadow Root，大量使用时内存开销明显；但比起用 class 模拟组件、靠 CSS scoped 或 JS 状态管理来“假装封装”，它反而更轻量、更可靠。
- 不要在
connectedCallback里重复 fetch 同一份数据——用外部状态或属性传入 -
<slot>是内容分发核心，但默认是匿名 slot；多插槽必须显式命名并用name="xxx"匹配 - 兼容性注意：
Edge 18-和部分旧安卓 WebView 不支持，需检查目标用户环境
为什么不用 <iframe> 做模块复用
<iframe> 看似能加载独立 HTML，但它带来的是跨文档通信、样式隔离、滚动同步、SEO 断层、首屏白屏等一系列新问题。它适合嵌入第三方内容（如地图、支付页），不适合内部模块复用。
真实场景中，有人用 <iframe src="header.html"> 替代 include，结果发现：无法响应父页面 CSS 变量、history.pushState 不同步、打印页面时 iframe 内容常被截断。
- 父页面无法用 CSS 选择器控制 iframe 内元素（除非同源且手动访问
contentDocument） - iframe 加载完成事件是
load，不是 DOMContentLoaded，监听时机容易错 - 移动端 Safari 对 iframe 的
height: 100%支持极差，常需 JS 计算高度
真正难的不是选哪种技术，而是判断模块是否“值得封装”：一个只在首页出现一次的 banner，硬套 Web Component 就是过度设计；而一个全站共用的登录弹窗，若仍靠复制粘贴 HTML，迟早出错。复用性来自约束，不是自由。
