HTML本身不支持原生模块导入机制，“模块化重整”必须依赖构建阶段预处理、运行时封装（如Web Components）或框架层抽象，否则仅是重复代码的物理拆分。
直接说结论：HTML 本身没有原生模块导入机制，所谓“模块化重整”不是给 <div> 加个 <code>import 就能解决的——它必须靠构建阶段介入、运行时封装或框架层抽象来落地，否则只是把重复代码从一个文件复制到多个文件而已。
HTML 文件间复用：为什么 include 在浏览器里根本跑不起来
很多人第一反应是“用服务器端 include”，比如 PHP 的 <?php include 'header.php'; ?>，或模板引擎里的 。这确实能复用，但前提是服务端渲染。纯静态 HTML + 原生浏览器打开时，include 标签不存在，<link rel="import"> 已被废弃，<iframe></iframe> 又带来样式隔离、SEO 和交互阻断问题。
- 浏览器直接双击打开
index.html，所有include语法都会原样输出为文本，不解析 -
<iframe src="header.html"></iframe>会触发额外 HTTP 请求，且内部 DOM 不属于主页面 document，JS 无法直接访问 - 想用 Fetch 动态加载再
innerHTML插入？会丢失 script 执行、破坏 CSP 策略、绕过 HTML 验证工具检查
真正可用的模块化路径：选构建时还是运行时
选择取决于你的部署方式和团队能力。构建时方案更稳定、可验证；运行时方案更灵活，但调试成本高。
-
构建时预处理（推荐）：用
posthtml-include或html-webpack-plugin+html-loader，在打包阶段把<include src="nav.html"></include>替换成真实内容。最终输出仍是标准 HTML，零运行时开销，HTMLHint 能正常校验 -
Web Components（渐进式）：用
customElements.define()注册<app-header></app-header>，配合<template></template>和<slot></slot>。Shadow DOM 隔离样式，但需注意：IE 完全不支持，旧版 Safari 需加 polyfill，且 SEO 友好度依赖 SSR 补充 -
框架组件（现实选择）：如果你项目已用 React/Vue，就别硬套原生 HTML 模块化。把
header.html改成Header.vue或Header.tsx，利用框架的编译时解析和热更新能力——这才是当前工程中真正可维护的“HTML 模块”
class 命名和结构重构：BEM 不是装饰，是模块边界的显式声明
模块化不只是拆文件，更是划清职责边界。BEM 的 block__element--modifier 不是为了好看，而是让每个 class 名自带作用域信息，避免改 card-title 时意外影响到另一个页面的 card-title。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
class="title"—— 全局污染，无法定位来源，重构时不敢动 - 正确写法：
class="product-card__title"—— 一眼看出归属模块，搜索product-card就能定位全部相关 HTML/CSS/JS - 嵌套层级超过两层（如
product-card__content__headline）说明模块粒度太粗，该拆而不是加深嵌套 - 所有模块级 class 必须以 block 名开头，禁止出现
global-button这类“伪模块”命名
验证和 CI：没进 pipeline 的模块化都是临时方案
模块化一旦引入，就必须有自动化手段守住底线。否则很快就会变成：header.html 被改了三次，但 footer.html 还停留在初始版本，各页面 header 渲染效果不一致。
- 在 CI 流程中加入
html-validate，配置规则强制检查所有<include></include>标签是否对应真实文件存在 - 对 Web Components，用 Puppeteer 启动无头浏览器，检查自定义标签是否成功 upgrade，Shadow DOM 内容是否渲染
- 禁止直接修改生成后的 dist 目录下 HTML —— 所有变更必须回溯到源模块文件，否则下次构建就覆盖掉
最常被忽略的一点：模块化之后，每个 HTML 片段的语义完整性容易被破坏。比如单独看 nav.html 缺少 或 <main></main> 上下文，验证工具会报错。解决方案不是关掉规则，而是用 html-validate 的 ignore 配置项，按文件路径精准忽略片段类文件，只校验最终合成的完整页面。
