提升HTML代码复用性的架构设计

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，迟早出错。复用性来自约束，不是自由。