html模块化不直接优化样式性能，其核心价值在于约束样式作用域、减少全局选择器污染、配合构建实现按需注入；语义标签不影响样式计算性能，真正关键的是类名规范、构建注入与作用域控制三者协同。
HTML 模块化本身不直接优化「样式性能」，它真正起作用的环节是：约束样式作用域、减少全局选择器污染、配合构建流程实现按需注入。单纯把 HTML 拆成多个 .html 文件再 <!--#include-->，反而会让 CSS 更难管理、更易冲突。
为什么用语义标签划分模块 ≠ 样式性能提升
很多人以为用了 <header></header>、<nav></nav> 就自动获得样式隔离或性能收益——其实不会。浏览器渲染时，<header class="navbar"></header> 和 <div class="navbar"> 在样式计算上完全等价；语义标签只影响 DOM 结构可读性、SEO 和辅助技术，不改变 CSS 选择器匹配开销或重排重绘成本。<p>真正影响样式性能的是：<code>class 命名是否导致长链选择器（如 .page .main .content .card .title）、是否全局污染（比如多个组件都用 .btn）、是否重复加载相同样式规则。
所以模块化必须落到「类名规范 + 构建注入 + 作用域控制」三者咬合，否则只是把样式混乱从一个文件扩散到多个文件。
用 BEM + 构建时 scoped class 前缀替代手写 include
原生 SSI 或 PHP include 无法在开发阶段解析组件参数，也无法自动为类名加前缀，结果就是：
- 所有组件共用
.button，改一个地方，全站按钮样式崩 - 组件内写
.button:hover，但外部全局* { box-sizing: border-box }被覆盖或冲突 - 热更新失效：改了
card.html，浏览器没刷新样式，因为 CSS 是单独打包的
正确做法是让构建工具（如 Vite）处理 HTML 片段：
1. 组件文件放在 src/components/card.v2.html，内容只写结构，不写样式类：
<article data-module="card"><br><h3><slot name="title"></slot></h3> <br><div><slot></slot></div> <br></article>
2. 构建时通过 vite-plugin-html 注入并自动重写类名：
源码中写 class="card__title" → 构建后变成 class="card-v2__title"
3. 对应 CSS 也走同一套命名映射，确保样式只作用于该版本组件，不泄漏、不冲突。
什么时候该用 Shadow DOM，而不是 class 前缀
当组件必须严格隔离样式、且能接受一定兼容性折损时，才考虑 customElements.define() + Shadow DOM：
- 好处：天然样式封闭，
:host、::slotted控制精准，不怕外部!important覆盖 - 坑点：
adoptedStyleSheets在 iOS Safari 16.4 之前不支持，slotfallback 内容在 SSR 时不可见 - 性能代价：每个 Shadow Root 都有独立样式表解析开销，10 个
<my-card></my-card>就是 10 次样式计算，不如单个 scoped class 高效
结论：内部管理后台、可控环境用 Shadow DOM 可行；面向公众的营销页、SEO 敏感页面，优先用 BEM + 构建时前缀，更稳、更轻、更易调试。
避免用 <template></template> + cloneNode 做运行时模块化
有人用 <template id="card">...</template> + JS 克隆插入，以为这样就能复用结构——但问题立刻浮现：
- 克隆出的节点没有自动绑定 scoped class，样式仍走全局
- 每次克隆都要重新解析 HTML 字符串，大量组件时 CPU 占用明显上升
- 无法静态分析 props 类型，IDE 不提示、TypeScript 不校验、重构易出错
如果真要运行时注入，至少配合 contentDocument 或手动创建 Shadow Root，并显式 appendChild 样式表——但这已超出 HTML 模块化范畴，属于 Web Components 实现细节了。
真正轻量又可靠的路径，还是回到构建时处理：HTML 片段作为模板，CSS 类名由工具统一注入，样式和结构在打包阶段就完成绑定。复杂点在于配置，容易被忽略的是——你得确保所有团队成员都在同一套构建规则下写组件，否则模块化就退化成“多人各自 include 一堆不兼容的 HTML”。
