HTML模块化需配合代码拆分才能落地，Custom Elements是当前最轻量原生载体，须用customElements.define()注册、含短横线命名，并通过shadow DOM隔离样式与逻辑。
HTML 模块化本身不强制依赖代码拆分，但实际工程中几乎必然要配合代码拆分才能落地——因为原生 <template>、<slot> 或自定义元素（Custom Elements）只是封装机制，不解决资源加载、作用域隔离和依赖管理问题。
HTML 模块化 ≠ HTML 文件拆分
很多人一看到“模块化”就立刻去切 header.html、footer.html，用 fetch() 拼接或服务端 include。这本质是模板拼接，不是模块化：没有依赖声明、无版本控制、无法复用、CSS/JS 作用域全靠人工规避。
- 原生
<link rel="import">已废弃，别再查兼容性了 -
<iframe>能隔离，但通信成本高、SEO 友好性差、样式 JS 完全割裂 - 真正可行的起点是：把一个可复用的 UI 单元（比如带搜索框的下拉菜单）封装成
<search-select>，它内部自带<style scoped>和初始化逻辑
Custom Elements 是当前最轻量的 HTML 模块化载体
它不要求构建工具，浏览器原生支持（Chrome 67+、Firefox 63+、Safari 16.4+），且天然支持依赖显式声明（通过 import）。
- 组件定义必须用
customElements.define()，名字里必须含短横线（如"data-table"），否则会报DOMException: Failed to execute 'define' on 'CustomElementRegistry' - 建议用
class extends HTMLElement+static get observedAttributes()响应属性变更，比轮询或 MutationObserver 更可靠 - Shadow DOM 默认启用（
this.attachShadow({mode: 'closed'})）能防止外部 CSS 泄漏，但也会让调试变难——DevTools 里看不到 shadow 内部的 computed styles，得手动展开#shadow-root
代码拆分不是可选项，而是加载策略问题
模块化组件如果全打包进主 HTML，就失去按需加载意义；但若每个组件都单独 import，又可能触发大量小文件请求。折中方案取决于场景：
立即学习“前端免费学习笔记（深入）”；
- 首屏强依赖组件（如导航栏）：内联
<script type="module">，避免额外 round-trip - 交互后才出现的组件（如弹窗表单）：用
await import('./dialog.js')动态导入，配合loading="lazy"或 IntersectionObserver 触发 - 第三方组件（如地图、图表）：检查是否提供 ESM 版本；若只有 UMD，用
import('https://unpkg.com/chart.js@4')动态加载，注意 CSP 限制 - 注意
import.meta.url是解析当前模块路径的唯一可靠方式，别用document.currentScript.src—— 在模块脚本里它始终是null
真正容易被忽略的是资源生命周期：Custom Element 实例被移除时，disconnectedCallback 里必须手动清理定时器、事件监听器和 IntersectionObserver 实例，否则内存泄漏比传统 jQuery 插件还隐蔽。
