直接回答：Web Components 是浏览器原生标准三件套：Custom Elements（注册自定义标签与生命周期）、Shadow DOM（样式与 DOM 隔离）、HTML Templates（惰性模板）。与框架不是替代而是不同层：WC 解决“跨技术栈可分发的 UI 元素”，框架解决“应用级状态驱动渲染”——WC 没有响应式系统、没有状态管理、属性只传字符串（复杂数据要走 property 赋值），构建复杂应用力不从心。

展开解析：真实适用场景：设计系统与组件库的跨框架分发——一套 button/tabs 组件同时服务 React、Vue、Angular 团队（Ionic、Shoelace、Adobe Spectrum 都走此路，框架方提供薄封装）；微前端集成的隔离边界——Shadow DOM 天然样式隔离，比 CSS 命名约定可靠；内容型可嵌入组件——播放器、图表这类“嵌入即走”的独立单元。不适用的场景：复杂表单与高频数据流应用（手写响应式绑定是自讨苦吃）、需要细粒度服务端渲染的场景（Declarative Shadow DOM 在普及中但生态支持参差）、深组件树通信（事件冒泡穿透 Shadow 边界要 composed 标记，心智负担大）。框架与 WC 的互操作现实：React 19 前对 custom element 的 property/事件支持残缺（只能传 attribute），19 起完善；Vue 对 WC 双向支持良好（defineCustomElement 可把 Vue 组件编译成 WC）。工程决策建议：组件库要跨栈就 WC 加各框架 wrapper；纯单栈应用直接用框架组件，WC 引入的隔离反而碍事（主题穿透、表单集成都麻烦）。lit/stencil 这类 WC 辅助库补足了响应式与模板语法，是认真使用 WC 的实际起点。

追问方向：Shadow DOM 对全局样式与 CSS 变量的穿透规则？WC 的可访问性（跨 shadow 边界 aria）难题？

（约 490 字）