Web Components是已落地的原生能力，customElements.define()等API在主流浏览器中无前缀运行；<dialog>和popover替代JS弹窗；Declarative Shadow DOM解决SSR FOUC；HTML Modules仍处草案阶段。
Web Components不是“未来技术”，而是已落地的原生能力
截至2026年，customElements.define()、ShadowRoot 和 <template> 在 Chrome 120+、Firefox 125+、Safari 17.4+ 中已无前缀、无 polyfill 正常运行。IE 和旧版 Edge 已退出主流支持范围，企业项目若仍需兼容 IE11，应明确接受 Web Components 无法启用的事实，而非强行套用 webcomponents.js —— 它在 Safari 16.4 以下会触发 Shadow DOM 渲染错位，且不支持 inert 或 popover 等新属性。
常见错误现象包括：组件内样式被外部 CSS 泄露覆盖、slot 内容未渲染、this.shadowRoot.querySelector() 返回 null（因调用时机早于 connectedCallback）。这些不是 bug，而是对生命周期理解偏差所致。
<dialog> 和 popover 正在替代 JS 弹窗逻辑
原生 <dialog> 不再需要 showModal() 才能获得模态行为：配合 open 属性 + popover="manual"，可实现非阻塞式浮层；而 popover="auto" 则自动处理焦点捕获与 Esc 关闭。这直接削弱了 aria-modal + focus-trap 类库的必要性。
使用场景差异明显：
立即学习“前端免费学习笔记（深入）”；
- 用
<dialog open>处理需要强中断的确认流（如删除操作） - 用
<div popover="manual">实现工具提示、下拉菜单等轻量交互 - 避免混用：同时设
open和popover会导致 Safari 17.5 渲染异常
性能影响很小，但语义正确性提升显著 —— 屏幕阅读器能原生识别 <dialog> 的角色，无需手动加 role="dialog"。
Declarative Shadow DOM 改变了 SSR 组件交付方式
服务端直出带 Shadow DOM 的组件，过去只能靠 hydration 补全，首屏存在 FOUC（Flash of Unstyled Content）。现在可在 HTML 中直接写：
<my-card>
<template shadowroot="open">
<style>h2 { color: var(--primary); }</style>
<slot name="title"></slot>
</template>
<h2 slot="title">Hello</h2>
</my-card>
浏览器解析到 shadowroot="open" 就立即挂载 Shadow DOM，跳过 JS 初始化。但注意三点：
- 仅支持
open模式，closed仍需 JS 创建 - 模板内不能含
<script>，事件绑定必须由宿主元素 JS 补充 - Webpack/Vite 默认会剥离
template[shadowroot]，需配置html-loader或vite-plugin-html保留
HTML Modules 仍未进入稳定阶段，别在生产环境用
虽然 WHATWG 已将 import 语法引入 HTML（<script type="module" src="comp.js"> 支持 import），但真正的 HTML Modules（即 import Component from "./card.html"）仍处于草案阶段，Chrome Canary 128 仅实验性开启，且禁用 CSP unsafe-eval 后会静默失败。
当前更稳妥的路径是：
- 用 ES 模块封装组件逻辑，HTML 模板仍走字符串或
<template>标签 - 构建时通过插件（如
rollup-plugin-html）预编译 HTML 片段为 JS 字符串导出 - 拒绝任何声称“已支持 HTML Modules”的 npm 包 —— 它们本质是字符串模板引擎，不是标准
真正值得投入的是语义化标签的组合使用：<details> + <summary> + inert + popover 已能覆盖 80% 的交互模式，比追逐未落地的模块语法更可靠。
