尧图网页设计 
原生前端框架的“终结”这个话题近两年讨论得特别多我自己的感受是浏览器原生能力已经补上了早年框架最核心的那几块拼图很多以前必须依赖框架的场景现在用原生 API 就能实现。我在几个项目里靠“原生 Web 组件”把运行时体积砍掉了一大截也踩过不少坑。这篇文章会把原生组件的核心机制、完整实操、容易被忽视的隐蔽陷阱连同选型建议一次性讲清楚适合正在做技术选型、想优化包体、或者准备建设跨框架组件库的人。1. 从框架到原生为什么“终结”之争不是标题党1.1 框架过去解决的核心问题现在被浏览器原生接管了回头看看前端框架这些年解决的本质问题其实就三件事一是组件化二是状态与 UI 同步三是跨浏览器一致性。jQuery 时代连遍历 DOM 都要写兼容代码后来 React 用声明式 UI 和虚拟 DOM 解决了“数据和视图怎么对齐”的痛点Vue 用响应式状态管理建立了一套更轻的心智模型。这些价值在十年前是刚需因为浏览器本身太原始。但今天的浏览器已经不原始了。Custom Elements 让你能直接定义属于自己的 HTML 标签Shadow DOM 把样式和 DOM 结构完整隔离HTML Templates 和 Slot 解决了组件组合问题ES Modules 加 import maps 提供了模块化方案。把这些能力拼在一起看你会发现框架当年最引以为傲的“组件化 状态同步 模块化”三板斧浏览器正在一门门地学回来。这不是概念上的想象。Chrome 这些年补齐了 ElementInternals、form-associated custom elements、Declarative Shadow DOMSafari 16.4 之后也跟上了大部分能力。相比五年前 Web Components 需要一堆 polyfill 才能用的状态现在原生组件已经是一个完全可落地的技术方案。我不认为框架会一夜之间消失但框架的边界确实在被原生能力一点一点挤压。1.2 框架的“体量税”与现实代价很多人讨论框架优劣喜欢看开发效率却低估了运行时体积的代价。React 在 gzip 压缩后仍有 40KB 以上Vue 也要 30KB 左右Angular 这种全家桶更不用说。对于复杂的中后台系统这几十 KB 可以忽略但对于内容站、营销页、电商小程序 Web 端每一 KB 都直接影响首屏加载和转化率。我在一个实际项目里做过统计页面真正需要框架特性的部分只占全部业务代码的三分之一其余部分就是一些可复用的交互组件——下拉、评分、树形菜单、图片懒加载、倒计时。这些交互通常不依赖全局状态管理却被框架运行时整体绑架了。后来我把这一层交互组件全部改造成原生 Web 组件项目 gzip 后的脚本体积直接降了 75% 左右首屏速度的提升非常明显。不要误会我并不是说框架没有价值。中后台复杂表单、跨页面状态流、路由状态同步这些场景框架依然是最合适的选择。但“所有页面都必须套一个重型框架”这个惯性思维确实该被打破。1.3 为什么说原生组件“终将胜出”更准确地说原生 Web 组件会吃掉框架最外围的那层“组件 UI”领地而框架会退居到应用编排层。你可以观察到一个清晰的信号Svelte 已经把大部分框架代码放进了编译期Solid 干脆强调“无虚拟 DOM”这些新框架的设计方向其实都是在向平台能力靠拢。像 React、Vue 这类传统框架最终可能变成“状态管理层 开发体验层”而底层的可复用 UI 单元越来越多会是标准浏览器组件。这个趋势和 Flutter 的路线是两回事——Flutter Web 是自绘渲染引擎走的是 Canvas/Skia 路线不依赖 DOM 组件体系。所以很多人在对比“Flutter 和其他前端框架优劣”时容易忽略一个前提如果你是做浏览器 Web 应用原生组件标准和 DOM 渲染路径才是真正的主赛道Flutter Web 更像是另一套生态的跨界尝试两者解决的方向完全不同。2. 原生 Web 组件必会的四个核心 API2.1 Custom Elements自定义标签不是魔法Custom Elements 是原生组件的基础它允许你注册一个全新的 HTML 标签比如icon-rating或user-card。注册时需要注意命名必须包含短横线这是 HTML 解析器区分标准元素和自定义元素的唯一依据。自定义元素分成两种。自主自定义元素是直接继承HTMLElement完全独立工作定制内置元素则通过is属性扩展现有元素比如把一个button扩展成button ismy-button。后者在 Safari 上支持得很糟糕我建议生产环境直接不做考虑统一走自主自定义元素路线跨浏览器行为最一致。生命周期回调是自定义元素的核心我整理成一张速查表回调触发时机常见用途connectedCallback元素插入文档时建立内部 DOM、绑定事件、加载数据disconnectedCallback元素从文档移除时清理定时器、解绑事件attributeChangedCallback被观察属性变化时响应属性变更、重渲染adoptedCallback元素被移动到新文档时重置文档相关状态有一个非常关键的细节构造函数里不能访问子元素、不能读取已有属性也不能操作 DOM。因为元素被构造时还没插入文档浏览器不允许你做这些事。所有初始化逻辑都要放到connectedCallback里。这是一个会和框架心智模型产生冲突的点习惯在 class 里直接赋值的开发者容易踩进去。2.2 Shadow DOM把样式和结构关进沙盒Shadow DOM 解决的是样式隔离和 DOM 封装。它给人的感觉很像给组件套了一个“透明罩子”外部 CSS 进不来内部 CSS 出不去document.querySelector也默认找不到内部的节点。常见误区是纠结attachShadow的 mode 参数。{ mode: open }和{ mode: closed }的区别在于外部能不能通过element.shadowRoot拿到内部根节点。实测下来 closed 模式没有真正安全价值因为它只是让普通代码拿不到 shadowRootDevTools 一样能看穿反而会让组件调试、第三方测试工具变得很困难。所以除非有极特殊需求一律用 open 模式就好。Shadow DOM 的边界也不是完全铁板一块。CSS 自定义属性CSS Variables可以穿透进入 shadowRoot:host选择器可以给宿主元素设置外部可见样式:defined伪类可以识别组件是否已注册。这些“穿透点”不是漏洞而是原生组件预留的定制化扩展入口后面实操部分会用到。2.3 HTML Templates 与 Slot组合优于继承template标签是个惰性片段它不会渲染到页面也不会触发资源加载。你要把它内部的内容克隆出来再塞进 shadowRoot 里。这在原生组件里充当了“组件模板”的角色。Slot 是原生组件的“插槽”机制相当于 Vue 的 slot 或 React 的 children。你可以在 Shadow DOM 里定义一个slot外部传入的任意内容就会被自动投影到这个位置。命名插槽可以通过name属性区分多个插入点还支持默认内容即外部不传内容时展示兜底文案。组合式设计的意义在于让组件的结构定义和内容填充彻底解耦。如果一个组件库想提供通用结构但允许调用方自由注入内容Slot 是比继承更符合前端习惯的组合方案这也是为什么原生组件标准中 Slot 的地位如此重要。2.4 现代 CSS 和 ES Modules让原生组件更像现代工程原生组件光用style注入样式会有点原始。现代浏览器支持 Constructable Stylesheet也就是用CSSStyleSheet对象创建样式表然后直接赋值给shadowRoot.adoptedStyleSheets。这么做的好处是同一个样式表对象能在多个组件实例间共享减少重复创建性能更好。模块化方面ES Modules 已经是浏览器一等公民。你可以把每个组件封装成独立的.js文件在页面里用script typemodule直接加载。配合 import maps甚至可以像 Node 一样写裸模块名导入不用构建工具也能实现基本的依赖管理。到这里你会发现原生 Web 组件的底层能力已经足够支撑一个工程化的组件体系组件定义、样式隔离、内容组合、模块加载全部有了官方标准。这也是我在项目里敢于把组件库从框架中抽离出来的底气。3. 用原生 API 手写一个 Production 的组件3.1 需求定义对外契约比实现逻辑更重要为了把前面章节的机制串起来我来手写一个可复用的评分组件icon-rating。它支持五颗星、点击打分、键盘左右箭头调整、只读模式、尺寸和颜色可配置还能接入原生表单直接提交数值。先定义它的“对外契约”这一步是原生组件设计里最容易被忽略但最重要的部分属性value0-5 的数值、readonly布尔、size小中大、color自定义主色事件changedetail 里带{ value }表单集成当组件放在form中时自动把 value 作为表单项值提交定义好这些不管内部实现如何变使用方依赖的接口就是稳定的。框架里的组件设计其实也是这样但原生组件的属性/事件语义是浏览器级标准天然跨框架通用。3.2 完整代码实现模板、样式、状态同步下面是一份可直接运行的完整实现我把代码放在一个名为icon-rating.js的模块里class IconRating extends HTMLElement { static get observedAttributes() { return [value, readonly, size, color]; } static get formAssociated() { return true; } constructor() { super(); // 表单关联能力必须在构造阶段就初始化 this._internals this.attachInternals(); } connectedCallback() { // 只初始化一次 DOM if (!this.shadowRoot) { this._render(); } this._bindEvents(); this._sync(); } attributeChangedCallback(name, oldValue, newValue) { if (oldValue newValue) return; // 未挂载时无需同步connectedCallback 会统一处理 if (this.isConnected this.shadowRoot) { this._sync(); } } _render() { const shadow this.attachShadow({ mode: open, delegatesFocus: true }); const style document.createElement(style); style.textContent :host { display: inline-flex; flex-wrap: wrap; align-items: center; gap: 0.25rem; font-size: var(--rating-size, 1.5rem); } :host([sizes]) { font-size: 1rem; } :host([sizel]) { font-size: 2rem; } .star { cursor: pointer; user-select: none; color: var(--rating-star-empty, #d1d5db); transition: color 0.15s ease; } .star.filled { color: var(--rating-star-filled, #f59e0b); } :host([readonly]) .star { cursor: default; } .star:focus-visible { outline: 2px solid var(--rating-focus, #2563eb); outline-offset: 2px; border-radius: 4px; } ; shadow.appendChild(style); const wrap document.createElement(span); wrap.setAttribute(role, radiogroup); wrap.setAttribute(aria-label, this.getAttribute(aria-label) || Rating); for (let i 1; i 5; i) { const star document.createElement(span); star.classList.add(star); star.dataset.value String(i); star.setAttribute(role, radio); star.textContent \u2605; wrap.appendChild(star); } shadow.appendChild(wrap); } _bindEvents() { if (this._bound) return; const shadow this.shadowRoot; shadow.addEventListener(click, (e) { const star e.target.closest(.star); if (!star || this.hasAttribute(readonly)) return; this.value Number(star.dataset.value); }); shadow.addEventListener(keydown, (e) { if (this.hasAttribute(readonly)) return; const star e.target.closest(.star); if (!star) return; let next Number(star.dataset.value); if (e.key ArrowRight) next Math.min(5, next 1); if (e.key ArrowLeft) next Math.max(1, next - 1); if (next ! Number(star.dataset.value)) { e.preventDefault(); this.value next; } }); this._bound true; } get value() { const v Number(this.getAttribute(value)); return Number.isNaN(v) ? 0 : v; } set value(v) { this.setAttribute(value, String(v)); } _sync() { const shadow this.shadowRoot; if (!shadow) return; const val this.value; const stars shadow.querySelectorAll(.star); stars.forEach((star, index) { const filled index Math.round(val); star.classList.toggle(filled, filled); star.setAttribute(aria-checked, String(index 1 Math.round(val))); star.setAttribute(tabindex, this.hasAttribute(readonly) ? -1 : 0); }); if (this._internals) { this._internals.setFormValue(val ? String(val) : null); } if (val) { this.dispatchEvent(new CustomEvent(change, { detail: { value: val }, bubbles: true, composed: true, })); } } } customElements.define(icon-rating, IconRating);页面里使用就很简单了form icon-rating namescore value3 sizel/icon-rating /form注意构造函数里必须调用attachInternals()否则后面的setFormValue会直接报错。static get formAssociated()声明了组件参与表单关联这一步缺失的话ElementInternals的很多 API 都无法工作。3.3 生命周期与渲染策略避免不必要的重绘这个组件的渲染策略我特意拆成了三层第一层是_render只在首次挂载时执行负责创建 Shadow DOM 和静态结构第二层是_sync负责响应属性变化更新类名和 ARIA 状态第三层是事件绑定只做一次通过_bound标志位防止重复绑定。这种拆法模仿了现代 UI 框架“创建虚拟节点 更新差异”的思路只不过在原生组件里更朴素。最忌讳的做法是每次属性变化就调用innerHTML重新生成所有星星这会让点击后焦点丢失、键盘导航错乱性能还很差。把“结构构建”和“状态同步”分开是原生组件达到生产级体验的第一步。另一个细节是attributeChangedCallback可能因为属性频繁变化而高频触发所以我在回调里加了isConnected this.shadowRoot判断避免组件未挂载时做无用功同时用oldValue newValue过滤无意义更新。3.4 跨框架使用React、Vue 都不需要改组件代码原生组件一个很大的优势是天然跨框架。Vue 3 对自定义元素的识别已经很成熟直接写icon-rating :valuerating changehandleChange就能工作Vue 会把change绑定到原生 change 事件上。React 方面要稍微注意React 的合成事件系统在历史上对自定义元素事件支持不友好尤其是 Shadow DOM 内部派发的事件。稳妥的做法是通过 ref 拿到组件实例后手动注册事件监听import React, { useRef, useEffect } from react; function Rating() { const ref useRef(null); useEffect(() { const el ref.current; const handler (e) { console.log(rating:, e.detail.value); }; el.addEventListener(change, handler); return () el.removeEventListener(change, handler); }, []); return icon-rating ref{ref} value3 /; }这段代码反映了一个现实问题原生组件虽然跨框架但不同框架对 DOM 事件模型的处理方式仍有差异。我的习惯是组件内部已经派发标准CustomEvent剩下的就是框架侧做一层薄封装而这个薄封装通常只需要几百字节。3.5 无构建工具直接使用的流程生产环境中我会把组件打包发布到 npm但如果你只想在项目中快速试一下完全可以不经过任何构建工具。建一个icon-rating.js文件然后在 HTML 里直接加载script typemodule src./icon-rating.js/script icon-rating value4 aria-label服务质量评分/icon-rating这种方式特别适合内部后台系统、营销页、CMS 页面避免为了一个交互组件拉起一整套 Node 工具链。你可以先写出来跑通再根据项目需要决定是否接入打包流程。4. 实操踩坑实录原生组件最隐蔽的六个陷阱4.1 表单组件的值不会自动提交这是原生组件被诟病最多的问题也是我自己第一次踩坑的地方。你以为把input放进 Shadow DOM容器组件放在form中表单提交时值就会自动带进去实际上不会。表单不会认识 Shadow DOM 内部的输入控件。正确的解决方式是使用ElementInternals。在构造阶段调用this.attachInternals()然后通过formAssociated静态属性声明参与表单关联。状态更新时调用setFormValue把值同步给宿主表单static get formAssociated() { return true; } constructor() { super(); this._internals this.attachInternals(); } _sync() { this._internals.setFormValue(this.value ? String(this.value) : null); }如果你需要表单校验还可以调用_internals.setValidity()。没有这套关联机制你的组件在表单里就只是个装饰品。这在 React 生态里不明显因为 React 自己管理表单状态但在原生 HTML 表单环境里这个坑必然遇到。4.2 键盘焦点管理需要 delegatesFocusShadow DOM 的封闭性也带来焦点问题。内部如果有input或可聚焦的按钮用户按 Tab 进入组件时浏览器默认把焦点落在外层:host上而不是落到内部第一个可交互元素。这在评分组件里表现为明明按了 Tab 到组件键盘左右调整却完全没有反应因为实际焦点根本不在星星上。解决办法是在attachShadow时加上delegatesFocus: truethis.attachShadow({ mode: open, delegatesFocus: true });这样 Enter 和空格键能正确触发内部可聚焦元素Tab 顺序也会更符合用户预期。可访问性测试时这个参数几乎必查建议做成组件库的默认选项。4.3 事件被“重定向”外部拿不到真实目标在 Shadow DOM 内部派发原生事件会触发事件重定向事件到了外部event.target会被自动改写为组件宿主元素而不是内部真正产生事件的星星节点。如果你的调用方想区分用户点了第几颗星直接监听原生 click 是拿不到的。这也是为什么评分组件里我主动派发自定义CustomEvent并把detail里带上 value。自定义事件要穿透 Shadow DOM 边界必须同时设置bubbles: true和composed: true。少了任何一个外部监听器都收不到。这个细节在框架集成时最容易制造“灵异现象”——组件在控制台点击明明有反应React/Vue 里却死活监听不到事件。4.4 全局 UI 框架的样式进不了 Shadow DOM用 Tailwind、Bootstrap、Element Plus 这类全局样式库的时候要特别注意它们默认不会作用于 Shadow DOM 内部。这个坑导致很多人一开始骂原生组件“样式写起来太痛苦”。我的建议是把组件样式完全放在组件内部通过 CSS 变量暴露可定制入口。比如评分组件的星星大小和颜色就分别映射到--rating-size、--rating-star-filled等变量。调用方可以这样定制icon-rating { --rating-size: 2.5rem; --rating-star-filled: #ef4444; --rating-star-empty: #e5e7eb; }这种“内部封闭、变量开放”的模式既是 Shadow DOM 的约束也是它带来的收益。如果你尝试把 Bootstrap 塞进 shadowRoot基本是自找麻烦直接在组件里设计好变量接口反而更干净。4.5 SSR/预渲染场景下首屏没有内容传统方式中用attachShadow构建 DOM 是运行时行为服务端渲染返回的 HTML 里没有任何组件内容。这对 SEO 或不支持 JavaScript 的环境非常不友好也是原生组件在 SSR 场景被吐槽最多的点。现在的标准方案是 Declarative Shadow DOM。你在服务端直接输出组件时可以在内部嵌套一个shadowrootmode属性为 open 的模板icon-rating value4 template shadowrootmodeopen style.../style span classstar filled★/span span classstar filled★/span ... /template /icon-rating浏览器解析到这种结构时会直接把模板转换为 Shadow DOM首屏渲染无需等待 JS。Chrome 90 和 Safari 16.4 都支持了这个特性。老一点的浏览器需要一个很小的 polyfill 做升级。这个能力让原生组件真正通向了 SSR 生产环境不再只是浏览器端的玩具。4.6 connectedCallback 反复触发别在它里面“放大招”在单页应用里元素的插入和移除会频繁触发connectedCallback和disconnectedCallback。比如一个列表做了虚拟滚动每一行组件都会被反复创建和销毁。如果你在connectedCallback里做了重活比如建立大对象、发起请求、重建 DOM性能会迅速劣化。更稳妥的做法是组件内部维护一个实例池或持久化缓存。DOM 结构只构建一次后续挂载只做状态同步。我在项目里遇到过表格行组件频繁重挂载导致页面卡顿后来改成“shadowRoot 跟着实例走状态更新走_sync”之后性能立刻恢复正常。这也是原生组件从 demo 走向生产必须跨过的一道坎。5. 技术选型决策指南原生还是框架5.1 一张表格快速判断适用场景做技术选型时不要因为“原生组件比较新”或者“框架生态丰富”就草率决定。我给自己的团队整理了一张判断表这里也分享给你场景推荐方向核心理由跨框架组件库/设计系统原生 Web 组件一套组件可在 React、Vue、Angular 中复用避免重复开发微前端架构原生 Web 组件各子应用技术栈隔离组件仍能保持统一复杂业务表单/全局状态管理框架数据流复杂时框架的响应式和状态容器收益更高首屏性能优先的营销页/小程序 Web原生组件无框架运行时gzip 体积优势显著团队已有成熟框架技术栈维持框架局部引入原生降低迁移风险新生组件用原生实现服务器端渲染为主的内容站原生组件 Declarative Shadow DOM无需 hydration首屏 HTML 即完整组件这张表的核心判断标准是你的瓶颈在“应用复杂度”还是“体积与复用成本”。如果是前者框架本身也是好工具如果是后者原生组件值得认真考虑。5.2 原生组件和其他前端框架的关系有人把 React、Vue、Svelte、Solid 这些统统归为“前端框架”然后拿来和原生组件对比。我觉得更合理的分类方式是看它们处于哪一层React 和 Vue 是应用层框架Svelte 和 Solid 试图把更多工作塞进编译期而原生 Web 组件是浏览器平台层能力。平台层能力一旦齐全所有应用层框架都会受益。Flutter Web 则走了一条完全不同的道路——它不依赖 DOM 组件体系而是自绘整个 UI。这种设计在跨端一致性和复杂动画上有独特优势但付出的代价是和 Web 生态的兼容成本较高。热搜里经常有人问“Flutter 和其他前端框架的优缺点”我的结论是如果你的主战场是浏览器原生 Web 组件和现代框架才是同一赛道的选手Flutter Web 更像另一个物种选择它等于选择一套独立的跨端渲染生态。5.3 混合架构才是我最推荐的落地方式我在新项目里最常用的方案是“框架做壳原生做组件”页面状态、路由、数据请求仍然交给 React 或 Vue但可复用的 UI 交互单元全部用原生 Web 组件实现打包成独立 npm 包分发。每个业务项目按需引用而不是被一个强框架绑定。这样做的最大收益是未来某个子应用从 React 迁移到 Vue基础组件库一行不改框架大版本升级也不会波及 UI 层。同时团队对新人的入门门槛也在降低因为原生组件遵循的是浏览器标准不依赖某个特定框架的 API。说实话“终结”这个词有点抓眼球我更愿意描述为浏览器在把当年框架赋予前端的能力一门门地收归标准。你不必明天就扔掉 React但我真心建议下一次写可复用组件时先试试短横线标签、shadowRoot 和自定义事件——这个尝试本身就是对你前端底层理解的一次重构。 原生Web组件实战：从核心机制到框架替代的完整指南
原生前端框架的“终结”这个话题近两年讨论得特别多我自己的感受是浏览器原生能力已经补上了早年框架最核心的那几块拼图很多以前必须依赖框架的场景现在用原生 API 就能实现。我在几个项目里靠“原生 Web 组件”把运行时体积砍掉了一大截也踩过不少坑。这篇文章会把原生组件的核心机制、完整实操、容易被忽视的隐蔽陷阱连同选型建议一次性讲清楚适合正在做技术选型、想优化包体、或者准备建设跨框架组件库的人。1. 从框架到原生为什么“终结”之争不是标题党1.1 框架过去解决的核心问题现在被浏览器原生接管了回头看看前端框架这些年解决的本质问题其实就三件事一是组件化二是状态与 UI 同步三是跨浏览器一致性。jQuery 时代连遍历 DOM 都要写兼容代码后来 React 用声明式 UI 和虚拟 DOM 解决了“数据和视图怎么对齐”的痛点Vue 用响应式状态管理建立了一套更轻的心智模型。这些价值在十年前是刚需因为浏览器本身太原始。但今天的浏览器已经不原始了。Custom Elements 让你能直接定义属于自己的 HTML 标签Shadow DOM 把样式和 DOM 结构完整隔离HTML Templates 和 Slot 解决了组件组合问题ES Modules 加 import maps 提供了模块化方案。把这些能力拼在一起看你会发现框架当年最引以为傲的“组件化 状态同步 模块化”三板斧浏览器正在一门门地学回来。这不是概念上的想象。Chrome 这些年补齐了 ElementInternals、form-associated custom elements、Declarative Shadow DOMSafari 16.4 之后也跟上了大部分能力。相比五年前 Web Components 需要一堆 polyfill 才能用的状态现在原生组件已经是一个完全可落地的技术方案。我不认为框架会一夜之间消失但框架的边界确实在被原生能力一点一点挤压。1.2 框架的“体量税”与现实代价很多人讨论框架优劣喜欢看开发效率却低估了运行时体积的代价。React 在 gzip 压缩后仍有 40KB 以上Vue 也要 30KB 左右Angular 这种全家桶更不用说。对于复杂的中后台系统这几十 KB 可以忽略但对于内容站、营销页、电商小程序 Web 端每一 KB 都直接影响首屏加载和转化率。我在一个实际项目里做过统计页面真正需要框架特性的部分只占全部业务代码的三分之一其余部分就是一些可复用的交互组件——下拉、评分、树形菜单、图片懒加载、倒计时。这些交互通常不依赖全局状态管理却被框架运行时整体绑架了。后来我把这一层交互组件全部改造成原生 Web 组件项目 gzip 后的脚本体积直接降了 75% 左右首屏速度的提升非常明显。不要误会我并不是说框架没有价值。中后台复杂表单、跨页面状态流、路由状态同步这些场景框架依然是最合适的选择。但“所有页面都必须套一个重型框架”这个惯性思维确实该被打破。1.3 为什么说原生组件“终将胜出”更准确地说原生 Web 组件会吃掉框架最外围的那层“组件 UI”领地而框架会退居到应用编排层。你可以观察到一个清晰的信号Svelte 已经把大部分框架代码放进了编译期Solid 干脆强调“无虚拟 DOM”这些新框架的设计方向其实都是在向平台能力靠拢。像 React、Vue 这类传统框架最终可能变成“状态管理层 开发体验层”而底层的可复用 UI 单元越来越多会是标准浏览器组件。这个趋势和 Flutter 的路线是两回事——Flutter Web 是自绘渲染引擎走的是 Canvas/Skia 路线不依赖 DOM 组件体系。所以很多人在对比“Flutter 和其他前端框架优劣”时容易忽略一个前提如果你是做浏览器 Web 应用原生组件标准和 DOM 渲染路径才是真正的主赛道Flutter Web 更像是另一套生态的跨界尝试两者解决的方向完全不同。2. 原生 Web 组件必会的四个核心 API2.1 Custom Elements自定义标签不是魔法Custom Elements 是原生组件的基础它允许你注册一个全新的 HTML 标签比如icon-rating或user-card。注册时需要注意命名必须包含短横线这是 HTML 解析器区分标准元素和自定义元素的唯一依据。自定义元素分成两种。自主自定义元素是直接继承HTMLElement完全独立工作定制内置元素则通过is属性扩展现有元素比如把一个button扩展成button ismy-button。后者在 Safari 上支持得很糟糕我建议生产环境直接不做考虑统一走自主自定义元素路线跨浏览器行为最一致。生命周期回调是自定义元素的核心我整理成一张速查表回调触发时机常见用途connectedCallback元素插入文档时建立内部 DOM、绑定事件、加载数据disconnectedCallback元素从文档移除时清理定时器、解绑事件attributeChangedCallback被观察属性变化时响应属性变更、重渲染adoptedCallback元素被移动到新文档时重置文档相关状态有一个非常关键的细节构造函数里不能访问子元素、不能读取已有属性也不能操作 DOM。因为元素被构造时还没插入文档浏览器不允许你做这些事。所有初始化逻辑都要放到connectedCallback里。这是一个会和框架心智模型产生冲突的点习惯在 class 里直接赋值的开发者容易踩进去。2.2 Shadow DOM把样式和结构关进沙盒Shadow DOM 解决的是样式隔离和 DOM 封装。它给人的感觉很像给组件套了一个“透明罩子”外部 CSS 进不来内部 CSS 出不去document.querySelector也默认找不到内部的节点。常见误区是纠结attachShadow的 mode 参数。{ mode: open }和{ mode: closed }的区别在于外部能不能通过element.shadowRoot拿到内部根节点。实测下来 closed 模式没有真正安全价值因为它只是让普通代码拿不到 shadowRootDevTools 一样能看穿反而会让组件调试、第三方测试工具变得很困难。所以除非有极特殊需求一律用 open 模式就好。Shadow DOM 的边界也不是完全铁板一块。CSS 自定义属性CSS Variables可以穿透进入 shadowRoot:host选择器可以给宿主元素设置外部可见样式:defined伪类可以识别组件是否已注册。这些“穿透点”不是漏洞而是原生组件预留的定制化扩展入口后面实操部分会用到。2.3 HTML Templates 与 Slot组合优于继承template标签是个惰性片段它不会渲染到页面也不会触发资源加载。你要把它内部的内容克隆出来再塞进 shadowRoot 里。这在原生组件里充当了“组件模板”的角色。Slot 是原生组件的“插槽”机制相当于 Vue 的 slot 或 React 的 children。你可以在 Shadow DOM 里定义一个slot外部传入的任意内容就会被自动投影到这个位置。命名插槽可以通过name属性区分多个插入点还支持默认内容即外部不传内容时展示兜底文案。组合式设计的意义在于让组件的结构定义和内容填充彻底解耦。如果一个组件库想提供通用结构但允许调用方自由注入内容Slot 是比继承更符合前端习惯的组合方案这也是为什么原生组件标准中 Slot 的地位如此重要。2.4 现代 CSS 和 ES Modules让原生组件更像现代工程原生组件光用style注入样式会有点原始。现代浏览器支持 Constructable Stylesheet也就是用CSSStyleSheet对象创建样式表然后直接赋值给shadowRoot.adoptedStyleSheets。这么做的好处是同一个样式表对象能在多个组件实例间共享减少重复创建性能更好。模块化方面ES Modules 已经是浏览器一等公民。你可以把每个组件封装成独立的.js文件在页面里用script typemodule直接加载。配合 import maps甚至可以像 Node 一样写裸模块名导入不用构建工具也能实现基本的依赖管理。到这里你会发现原生 Web 组件的底层能力已经足够支撑一个工程化的组件体系组件定义、样式隔离、内容组合、模块加载全部有了官方标准。这也是我在项目里敢于把组件库从框架中抽离出来的底气。3. 用原生 API 手写一个 Production 的组件3.1 需求定义对外契约比实现逻辑更重要为了把前面章节的机制串起来我来手写一个可复用的评分组件icon-rating。它支持五颗星、点击打分、键盘左右箭头调整、只读模式、尺寸和颜色可配置还能接入原生表单直接提交数值。先定义它的“对外契约”这一步是原生组件设计里最容易被忽略但最重要的部分属性value0-5 的数值、readonly布尔、size小中大、color自定义主色事件changedetail 里带{ value }表单集成当组件放在form中时自动把 value 作为表单项值提交定义好这些不管内部实现如何变使用方依赖的接口就是稳定的。框架里的组件设计其实也是这样但原生组件的属性/事件语义是浏览器级标准天然跨框架通用。3.2 完整代码实现模板、样式、状态同步下面是一份可直接运行的完整实现我把代码放在一个名为icon-rating.js的模块里class IconRating extends HTMLElement { static get observedAttributes() { return [value, readonly, size, color]; } static get formAssociated() { return true; } constructor() { super(); // 表单关联能力必须在构造阶段就初始化 this._internals this.attachInternals(); } connectedCallback() { // 只初始化一次 DOM if (!this.shadowRoot) { this._render(); } this._bindEvents(); this._sync(); } attributeChangedCallback(name, oldValue, newValue) { if (oldValue newValue) return; // 未挂载时无需同步connectedCallback 会统一处理 if (this.isConnected this.shadowRoot) { this._sync(); } } _render() { const shadow this.attachShadow({ mode: open, delegatesFocus: true }); const style document.createElement(style); style.textContent :host { display: inline-flex; flex-wrap: wrap; align-items: center; gap: 0.25rem; font-size: var(--rating-size, 1.5rem); } :host([sizes]) { font-size: 1rem; } :host([sizel]) { font-size: 2rem; } .star { cursor: pointer; user-select: none; color: var(--rating-star-empty, #d1d5db); transition: color 0.15s ease; } .star.filled { color: var(--rating-star-filled, #f59e0b); } :host([readonly]) .star { cursor: default; } .star:focus-visible { outline: 2px solid var(--rating-focus, #2563eb); outline-offset: 2px; border-radius: 4px; } ; shadow.appendChild(style); const wrap document.createElement(span); wrap.setAttribute(role, radiogroup); wrap.setAttribute(aria-label, this.getAttribute(aria-label) || Rating); for (let i 1; i 5; i) { const star document.createElement(span); star.classList.add(star); star.dataset.value String(i); star.setAttribute(role, radio); star.textContent \u2605; wrap.appendChild(star); } shadow.appendChild(wrap); } _bindEvents() { if (this._bound) return; const shadow this.shadowRoot; shadow.addEventListener(click, (e) { const star e.target.closest(.star); if (!star || this.hasAttribute(readonly)) return; this.value Number(star.dataset.value); }); shadow.addEventListener(keydown, (e) { if (this.hasAttribute(readonly)) return; const star e.target.closest(.star); if (!star) return; let next Number(star.dataset.value); if (e.key ArrowRight) next Math.min(5, next 1); if (e.key ArrowLeft) next Math.max(1, next - 1); if (next ! Number(star.dataset.value)) { e.preventDefault(); this.value next; } }); this._bound true; } get value() { const v Number(this.getAttribute(value)); return Number.isNaN(v) ? 0 : v; } set value(v) { this.setAttribute(value, String(v)); } _sync() { const shadow this.shadowRoot; if (!shadow) return; const val this.value; const stars shadow.querySelectorAll(.star); stars.forEach((star, index) { const filled index Math.round(val); star.classList.toggle(filled, filled); star.setAttribute(aria-checked, String(index 1 Math.round(val))); star.setAttribute(tabindex, this.hasAttribute(readonly) ? -1 : 0); }); if (this._internals) { this._internals.setFormValue(val ? String(val) : null); } if (val) { this.dispatchEvent(new CustomEvent(change, { detail: { value: val }, bubbles: true, composed: true, })); } } } customElements.define(icon-rating, IconRating);页面里使用就很简单了form icon-rating namescore value3 sizel/icon-rating /form注意构造函数里必须调用attachInternals()否则后面的setFormValue会直接报错。static get formAssociated()声明了组件参与表单关联这一步缺失的话ElementInternals的很多 API 都无法工作。3.3 生命周期与渲染策略避免不必要的重绘这个组件的渲染策略我特意拆成了三层第一层是_render只在首次挂载时执行负责创建 Shadow DOM 和静态结构第二层是_sync负责响应属性变化更新类名和 ARIA 状态第三层是事件绑定只做一次通过_bound标志位防止重复绑定。这种拆法模仿了现代 UI 框架“创建虚拟节点 更新差异”的思路只不过在原生组件里更朴素。最忌讳的做法是每次属性变化就调用innerHTML重新生成所有星星这会让点击后焦点丢失、键盘导航错乱性能还很差。把“结构构建”和“状态同步”分开是原生组件达到生产级体验的第一步。另一个细节是attributeChangedCallback可能因为属性频繁变化而高频触发所以我在回调里加了isConnected this.shadowRoot判断避免组件未挂载时做无用功同时用oldValue newValue过滤无意义更新。3.4 跨框架使用React、Vue 都不需要改组件代码原生组件一个很大的优势是天然跨框架。Vue 3 对自定义元素的识别已经很成熟直接写icon-rating :valuerating changehandleChange就能工作Vue 会把change绑定到原生 change 事件上。React 方面要稍微注意React 的合成事件系统在历史上对自定义元素事件支持不友好尤其是 Shadow DOM 内部派发的事件。稳妥的做法是通过 ref 拿到组件实例后手动注册事件监听import React, { useRef, useEffect } from react; function Rating() { const ref useRef(null); useEffect(() { const el ref.current; const handler (e) { console.log(rating:, e.detail.value); }; el.addEventListener(change, handler); return () el.removeEventListener(change, handler); }, []); return icon-rating ref{ref} value3 /; }这段代码反映了一个现实问题原生组件虽然跨框架但不同框架对 DOM 事件模型的处理方式仍有差异。我的习惯是组件内部已经派发标准CustomEvent剩下的就是框架侧做一层薄封装而这个薄封装通常只需要几百字节。3.5 无构建工具直接使用的流程生产环境中我会把组件打包发布到 npm但如果你只想在项目中快速试一下完全可以不经过任何构建工具。建一个icon-rating.js文件然后在 HTML 里直接加载script typemodule src./icon-rating.js/script icon-rating value4 aria-label服务质量评分/icon-rating这种方式特别适合内部后台系统、营销页、CMS 页面避免为了一个交互组件拉起一整套 Node 工具链。你可以先写出来跑通再根据项目需要决定是否接入打包流程。4. 实操踩坑实录原生组件最隐蔽的六个陷阱4.1 表单组件的值不会自动提交这是原生组件被诟病最多的问题也是我自己第一次踩坑的地方。你以为把input放进 Shadow DOM容器组件放在form中表单提交时值就会自动带进去实际上不会。表单不会认识 Shadow DOM 内部的输入控件。正确的解决方式是使用ElementInternals。在构造阶段调用this.attachInternals()然后通过formAssociated静态属性声明参与表单关联。状态更新时调用setFormValue把值同步给宿主表单static get formAssociated() { return true; } constructor() { super(); this._internals this.attachInternals(); } _sync() { this._internals.setFormValue(this.value ? String(this.value) : null); }如果你需要表单校验还可以调用_internals.setValidity()。没有这套关联机制你的组件在表单里就只是个装饰品。这在 React 生态里不明显因为 React 自己管理表单状态但在原生 HTML 表单环境里这个坑必然遇到。4.2 键盘焦点管理需要 delegatesFocusShadow DOM 的封闭性也带来焦点问题。内部如果有input或可聚焦的按钮用户按 Tab 进入组件时浏览器默认把焦点落在外层:host上而不是落到内部第一个可交互元素。这在评分组件里表现为明明按了 Tab 到组件键盘左右调整却完全没有反应因为实际焦点根本不在星星上。解决办法是在attachShadow时加上delegatesFocus: truethis.attachShadow({ mode: open, delegatesFocus: true });这样 Enter 和空格键能正确触发内部可聚焦元素Tab 顺序也会更符合用户预期。可访问性测试时这个参数几乎必查建议做成组件库的默认选项。4.3 事件被“重定向”外部拿不到真实目标在 Shadow DOM 内部派发原生事件会触发事件重定向事件到了外部event.target会被自动改写为组件宿主元素而不是内部真正产生事件的星星节点。如果你的调用方想区分用户点了第几颗星直接监听原生 click 是拿不到的。这也是为什么评分组件里我主动派发自定义CustomEvent并把detail里带上 value。自定义事件要穿透 Shadow DOM 边界必须同时设置bubbles: true和composed: true。少了任何一个外部监听器都收不到。这个细节在框架集成时最容易制造“灵异现象”——组件在控制台点击明明有反应React/Vue 里却死活监听不到事件。4.4 全局 UI 框架的样式进不了 Shadow DOM用 Tailwind、Bootstrap、Element Plus 这类全局样式库的时候要特别注意它们默认不会作用于 Shadow DOM 内部。这个坑导致很多人一开始骂原生组件“样式写起来太痛苦”。我的建议是把组件样式完全放在组件内部通过 CSS 变量暴露可定制入口。比如评分组件的星星大小和颜色就分别映射到--rating-size、--rating-star-filled等变量。调用方可以这样定制icon-rating { --rating-size: 2.5rem; --rating-star-filled: #ef4444; --rating-star-empty: #e5e7eb; }这种“内部封闭、变量开放”的模式既是 Shadow DOM 的约束也是它带来的收益。如果你尝试把 Bootstrap 塞进 shadowRoot基本是自找麻烦直接在组件里设计好变量接口反而更干净。4.5 SSR/预渲染场景下首屏没有内容传统方式中用attachShadow构建 DOM 是运行时行为服务端渲染返回的 HTML 里没有任何组件内容。这对 SEO 或不支持 JavaScript 的环境非常不友好也是原生组件在 SSR 场景被吐槽最多的点。现在的标准方案是 Declarative Shadow DOM。你在服务端直接输出组件时可以在内部嵌套一个shadowrootmode属性为 open 的模板icon-rating value4 template shadowrootmodeopen style.../style span classstar filled★/span span classstar filled★/span ... /template /icon-rating浏览器解析到这种结构时会直接把模板转换为 Shadow DOM首屏渲染无需等待 JS。Chrome 90 和 Safari 16.4 都支持了这个特性。老一点的浏览器需要一个很小的 polyfill 做升级。这个能力让原生组件真正通向了 SSR 生产环境不再只是浏览器端的玩具。4.6 connectedCallback 反复触发别在它里面“放大招”在单页应用里元素的插入和移除会频繁触发connectedCallback和disconnectedCallback。比如一个列表做了虚拟滚动每一行组件都会被反复创建和销毁。如果你在connectedCallback里做了重活比如建立大对象、发起请求、重建 DOM性能会迅速劣化。更稳妥的做法是组件内部维护一个实例池或持久化缓存。DOM 结构只构建一次后续挂载只做状态同步。我在项目里遇到过表格行组件频繁重挂载导致页面卡顿后来改成“shadowRoot 跟着实例走状态更新走_sync”之后性能立刻恢复正常。这也是原生组件从 demo 走向生产必须跨过的一道坎。5. 技术选型决策指南原生还是框架5.1 一张表格快速判断适用场景做技术选型时不要因为“原生组件比较新”或者“框架生态丰富”就草率决定。我给自己的团队整理了一张判断表这里也分享给你场景推荐方向核心理由跨框架组件库/设计系统原生 Web 组件一套组件可在 React、Vue、Angular 中复用避免重复开发微前端架构原生 Web 组件各子应用技术栈隔离组件仍能保持统一复杂业务表单/全局状态管理框架数据流复杂时框架的响应式和状态容器收益更高首屏性能优先的营销页/小程序 Web原生组件无框架运行时gzip 体积优势显著团队已有成熟框架技术栈维持框架局部引入原生降低迁移风险新生组件用原生实现服务器端渲染为主的内容站原生组件 Declarative Shadow DOM无需 hydration首屏 HTML 即完整组件这张表的核心判断标准是你的瓶颈在“应用复杂度”还是“体积与复用成本”。如果是前者框架本身也是好工具如果是后者原生组件值得认真考虑。5.2 原生组件和其他前端框架的关系有人把 React、Vue、Svelte、Solid 这些统统归为“前端框架”然后拿来和原生组件对比。我觉得更合理的分类方式是看它们处于哪一层React 和 Vue 是应用层框架Svelte 和 Solid 试图把更多工作塞进编译期而原生 Web 组件是浏览器平台层能力。平台层能力一旦齐全所有应用层框架都会受益。Flutter Web 则走了一条完全不同的道路——它不依赖 DOM 组件体系而是自绘整个 UI。这种设计在跨端一致性和复杂动画上有独特优势但付出的代价是和 Web 生态的兼容成本较高。热搜里经常有人问“Flutter 和其他前端框架的优缺点”我的结论是如果你的主战场是浏览器原生 Web 组件和现代框架才是同一赛道的选手Flutter Web 更像另一个物种选择它等于选择一套独立的跨端渲染生态。5.3 混合架构才是我最推荐的落地方式我在新项目里最常用的方案是“框架做壳原生做组件”页面状态、路由、数据请求仍然交给 React 或 Vue但可复用的 UI 交互单元全部用原生 Web 组件实现打包成独立 npm 包分发。每个业务项目按需引用而不是被一个强框架绑定。这样做的最大收益是未来某个子应用从 React 迁移到 Vue基础组件库一行不改框架大版本升级也不会波及 UI 层。同时团队对新人的入门门槛也在降低因为原生组件遵循的是浏览器标准不依赖某个特定框架的 API。说实话“终结”这个词有点抓眼球我更愿意描述为浏览器在把当年框架赋予前端的能力一门门地收归标准。你不必明天就扔掉 React但我真心建议下一次写可复用组件时先试试短横线标签、shadowRoot 和自定义事件——这个尝试本身就是对你前端底层理解的一次重构。