我必须提前说明下面这篇博文围绕的是“信号Signals”这种前端响应式机制和硬件里的信号处理完全是两码事。但有趣的是我翻热搜词时看到“信号混叠失真”“信号完整性”“采样、抗混叠滤波与信号重建”这些词被搜得很热它们其实是电子工程里的术语。我写完之后发现用硬件信号处理的思维去理解前端 Signal 的某些坑居然特别顺。所以这篇会中间穿插一点这种跨界的类比帮大家换个角度想问题。1. 虚拟DOM的黄金时代账本是怎么一步步算不明白的先说个结论虚拟DOM没死只是“性价比”开始出问题了。2026年的前端框架集体转向信号Signals本质不是虚拟DOM技术烂而是业务场景变了硬件环境变了开发者对性能的敏感度也变了。这就像当年jQuery被React取代一样不是jQuery写不了页面而是复杂应用的状态同步成本太高虚拟DOM这套“全量对比再局部更新”的思路在最开始很优雅但规模一大、交互一密账就算不过来了。1.1 虚拟DOM为什么能统治这么多年虚拟DOM核心贡献是让前端从“命令式操作DOM”迈向了“声明式描述UI”。你只需要描述某个状态长什么样框架负责算出真实DOM该怎么改。它的杀手锏是diff算法新旧两棵虚拟节点树做对比找出最小差异再批量更新到页面上。面试里常问的“虚拟dom和diff算法”本质上就是在考你对这套机制的底层理解key的作用、同层对比策略、双端diff的优化等。这套机制在2015年前后是降维打击。那时候单页应用刚刚爆发前端要管理的数据复杂度远没有今天夸张diff一次几百个节点的成本可以忽略。更重要的是虚拟DOM带来了跨平台能力——同一个渲染描述层可以映射到DOM、原生组件、CanvasReact Native就是这么长出来的。说白了虚拟DOM是描述UI的一种中间格式它最值钱的是那层“抽象”而不是diff本身。1.2 性能账单上的三座大山虚拟DOM有几个成本是绕不开的。第一每次状态变化通常要从根组件或者触发组件开始重新执行render函数生成一棵全新的虚拟节点树。哪怕只有一个很小的状态变了整个组件子树都要重新跑一遍代码逻辑。React里那个经典的“父组件setState子组件跟着重渲染”就是这棵树的结构性成本。第二虚拟节点对象的创建和销毁会产生大量对象分配。一屏列表1000行每行20个节点一次全量渲染就是2万个对象。如果是每秒更新好几次的实时仪表盘GC压力肉眼可见。我实习的时候维护过一个老React项目打开性能面板满屏的Minor GC标记帧率掉到40fps以下就是虚拟DOM对象在内存里频繁生灭造成的。第三是水合Hydration成本。服务端渲染出的HTML要在浏览器端“复活”成可交互应用React的经典做法是生成虚拟DOM树去对标现有DOM结构分配事件处理器。这套逻辑在复杂页面里非常重用户看着首屏HTML已经出来了但页面要过好久才能点击本质就是水合在拖后腿。业内搜“前端框架最新框架”“虚拟dom和diff算法面试”的高频词背后对应的其实是同一个焦虑虚拟DOM的性能模型开始跟不上产品复杂度了。1.3 为什么偏要等到2026年才“背叛”技术转向从来不是一夜之间的事。信号的底层思想——数据对象本身具有响应能力谁读取了它就把谁记进依赖表值一变直接通知订阅者——其实2010年以前就在Knockout、MobX这些库里出现过。但那时候这门手艺有几个硬伤依赖收集容易漏、update时序容易乱、循环依赖难排查社区吃过亏之后敬而远之。真正让Signal翻身的是过去五六年工程实践的成熟。如今前端页面交互密度大幅提升高频实时数据、协作编辑器、数据可视化大屏成为刚需而智能手表、车载中控、低端安卓机这类受限设备也要跑复杂前端。这些场景里“更新一个数却要对比整棵组件树”的虚拟DOM模型太奢侈了信号机制按需连接、精准更新的特性正好命中痛点。所谓2026年的集体转向其实是信号工程化成熟之后市场情绪的自然转折点。2. 信号的本质把“通知”变成一次精确的“广播”如果让我用一句话解释信号我会说虚拟DOM是“定期告诉你全公司所有人的状态”信号是“谁变了就只给关心他的人发一条消息”。前者省心但量大。后者需要先建立一套完整的订阅关系可一旦建好每次更新的成本几乎等于零。2.1 最朴素的理解模型灯泡和开关想象一个控制面板上面有一排灯泡每个灯泡背后连着一个特定的开关。虚拟DOM的做法是你不知道哪个开关管哪个灯所以每次有人操作面板你就把整排灯泡全部检查一遍看哪个该亮哪个该灭。信号的做法是施工时就把线一对一接好某个开关按下去只有对应的那盏灯收到电流。放到前端场景里开关就是“状态单元”灯泡就是“读取了该状态的视图片段或副作用”。Signal框架在运行时维护一张依赖图数据被读取时读取方自动注册为依赖者数据被写入时直接向这一组依赖者发送更新通知。这就是为什么Signal更新粒度可以达到“单个组件内部的一段JSX表达式”这个级别而不是整个组件重新渲染。这套模型带来的直接好处是内存里不再需要持久保存一棵庞大的虚拟DOM树作为“预演层”真实DOM本身就是渲染结果。更新时不需要生成新对象去对比差异改一个值就把对应的DOM节点文本直接改掉。好多人问“信号还要不要diff算法”答案是不需要了。依赖关系图本身就是“哪段UI依赖哪个状态”的精确索引根本不存在“全量对比找差异”的阶段。2.2 依赖收集背后的微机制push和pull之争信号系统在实现上分两个流派。一类是Push模型数据变化后主动推送给所有下游依赖通知链路长、中间产物多但响应快。另一类是Pull模型数据变化只标记一个“脏”状态等真正需要读取结果时才向上游重新计算。Pull模型的极端代表是Solid它的更新是“推拉结合”状态变更先推送到边界组件具体谁要更新由组件内部精确定位。为什么这么折腾因为纯Push模型遇到“一个状态被上千个计算属性依赖”时会引发重复计算。Pure Pull模型则可能导致更新不及时。实际工程中大部分框架都在两个极端之间做平衡既要用依赖表控制传播范围又要用惰性求值减少无效计算。这里“多bit信号跨时钟域”那种硬件工程师爱聊的问题其实前端也会遇到——不同数据源在不同时机更新时如何保证信号在“同一帧”里的一致性这个等会儿在第五章细说。2.3 与虚拟DOM的三层底层差异第一层差异是更新粒度。虚拟DOM的最小更新单位通常是一个组件函数而信号的最小更新单位是一个数据绑定表达式。第二层差异是调度方式。虚拟DOM框架一般通过“一次事件循环内自动批量更新”来合并状态变化信号框架同样有批处理但它的依赖图天然知道哪些字段发生了变化可以更精准地跳过无关更新。第三层差异是内存结构。虚拟DOM需要维护一棵持续的节点树信号维护的则是一张依赖关系图节点数量更少连接关系更明确回收更干净。这些差异带来的结果不是“快了多少”而是“省了多少”。省的是主线程上无意义的JS执行省的是内存垃圾回收压力省的是渲染进程里“莫名其妙被重渲染”的排查时间。我在实际项目里最强烈的感受是用信号框架写的复杂表格更新单元格时你几乎感觉不到主线程在工作而用老虚拟DOM框架2000行数据的表格随便改一格CPU曲线至少要跳一下。3. 2026年主流框架的“信号宣言”一个比一个决绝“前端框架最新框架”的热搜词在2026年基本指向同一件事头部框架全部把信号作为一等公民。有的像Solid从第一天就长在信号上有的是半路转型比如Vue、Angular、Svelte还有React靠编译器在虚拟DOM内部偷偷模拟信号行为。方向相同打法各异。3.1 Solid从头到尾就是信号的形状Solid是我认为最“纯粹”的信号框架。它的JSX不是虚拟DOM模板而是一层编译语法糖编译后直接生成对真实DOM的精确插入操作。比如这样import { createSignal } from solid-js; function Counter() { const [count, setCount] createSignal(0); const double () count() * 2; return ( div p当前值{count()}/p p两倍值{double()}/p button onClick{() setCount(c c 1)}加一/button /div ); }编译之后这个组件里的count()调用点会直接变成一个数据绑定表达式。setCount时Solid运行时直接定位到那两个p元素并更新textContent不会重新执行整段JSX逻辑也不会重建虚拟节点。我第一次跑Solid性能测试时说实话有点恍惚两千行的表格点击单元格改一个值录制的Performance面板几乎看不到长任务。后来仔细想想也合理虚拟DOM省的是“避免全量DOM更新”的成本信号省的是“连组件逻辑全量重跑都省了”不在一个量级。3.2 Vue从响应式到Signal的自然回归很多人不知道Vue从2.0开始就有了一套完整的依赖追踪系统data里的对象被getter/setter包裹render函数里读取了谁就收集谁数据变化精确触发相关组件更新。这套机制其实已经是信号的雏形。真正让Vue在信号阵营里站稳脚跟的是3.4之后ref、computed、watchEffect这组API在编译器层Vapor Mode的支持。Vapor模式绕过了虚拟DOM模板直接编译成细粒度的指令更新。看一段直观的例子import { ref, computed } from vue; const count ref(0); const double computed(() count.value * 2); watchEffect(() { document.title 当前${count.value}两倍${double.value}; }); count.value;这里computed自带缓存和依赖追踪只有count变化时才会重新计算。Vapor模式跑这种代码时更新路径上没有虚拟DOM模板里的插值点是直接编译成指令的。Vue最聪明的点是保留了响应式心智模型让老用户几乎无痛过渡。我周围不少Vue新手根本不知道模板里每个{{ }}背后其实是一个信号绑定这种“无感知”恰恰说明信号机制可以做到多自然。3.3 Angular、Svelte、Preact各有各的“跳法”Angular在v16之后正式引入signalAPIv17又把变更检测机制全面重构为基于信号的细粒度更新。原先那个强悍却沉重的Zone.js全局检测机制终于等到了一套更精确的替代方案。Svelte 5则通过Runes语法把信号机制放进了语言层比如这么写script let count $state(0); const double $derived(count * 2); $effect(() console.log(count)); /script p{count} / {double}/p button onclick{() count}加一/button$state、$derived、$effect看着像框架魔法本质就是信号的三件套可变状态、派生值、副作用。Preact更直接发布了独立的preact/signals包你甚至可以在React项目里局部引入信号机制不改变组件树结构就能对高频模块精准优化。3.4 React嘴上说不要身体还是诚实的React官方至今没有把信号作为一等公民因为它最强的资产是跨平台抽象层——虚拟DOM是连接Web、React Native、Canvas的统一描述格式。如果全面转向信号这套跨平台模型就得推翻重来。但React不是没动作React Compiler的思路是在保留虚拟DOM外壳的前提下自动识别数据依赖关系为每个组件生成细粒度的缓存避免无意义的重复渲染。换句话说React试图用编译器把“手动优化”变成“自动完成”在结果上接近信号的效果但底层的虚拟DOM树仍然存在。对这个路线我个人的判断是它能让旧项目平滑升级但性能上限不如原生信号框架。原因很简单只要保留虚拟DOM树GC压力和水合成本就不可能完全消失。React的价值在于“存量市场”和“跨平台生态”如果哪天React Native彻底成熟、框架团队找到同时保住抽象层和细粒度更新的办法那才是真正的技术奇点。4. 实战对比从性能数据到开发体验一张表说清楚我在做技术选型时最烦“无脑吹性能”所以这里打算给出一套自己用的对比思路不是推广某个框架而是帮你在做决定时有个决策框架。4.1 我的一套对比基准思路我会同时跑三个场景大表格高频更新1000行×20列每200ms随机改一个单元格、实时数据流图表每秒20个数据点追加带动折线图重绘、长列表滚动1万条数据带复杂行组件。指标不只看FPS还要看长任务数量、JS堆内存波动、GC暂停时间。单独看FPS很容易被骗因为现在大部分框架都能用“节流”或“并发调度”把掉帧藏起来但内存曲线骗不了人。实测下来VirtualDOM框架在第一个场景里JS堆会周期性跳高因为每次更新都会创建一轮临时虚拟节点对象。信号框架的曲线则平稳得多它只更新绑定片段没有大规模临时对象。这个差异在低端安卓机上会被放大虚拟DOM框架容易触发频繁GCGC一跑就卡卡就掉帧。这不是框架BUG而是内存模型的底层差异。4.2 内存与CPU账本谁动用了更多的“物资”虚拟DOM的一次全量渲染消耗可以用一个很简单的公式估算临时对象数≈组件数量×平均节点数×渲染频率。信号框架的临时对象数≈更新触发的绑定片段数二者往往差一个数量级。我见过一个真实项目优化案例把高频轮询模块从虚拟DOM迁移到信号后JS堆峰值从45MB降到22MB长任务从每帧都有变成几乎为0。这里面没有深奥的优化技巧全靠“少建临时对象”。CPU上的差异更直接。虚拟DOM框架每次更新都要经过“render生成新树→diff对比新旧树→提交到真实DOM”三阶段哪怕优化再好函数调用和对象遍历的开销都省不掉。信号框架省略了前两步直接从“状态节点”走到“DOM绑定节点”。还是那句老话——不是信号快是虚拟DOM干了很多这个场景里根本不需要干的活。4.3 水合、并发与信号的新问题SSR下的水合是虚拟DOM的经典痛点信号框架的解法要干净得多服务端输出的HTML自带标记客户端初始化时只建立依赖关系不需要重新执行一遍完整的组件树逻辑来对齐状态。所以用Solid或Vapor模式做巨长页面时可交互时间能缩短不少。不过信号也有自己的软肋并发调度。React的并发特性可以在多任务之间切分CPU时间片保证输入响应不卡顿。而大多数信号框架目前的更新是同步的一次状态变更会顺着依赖图一路执行到底。遇到“一个状态变化带动上千个派生值重算”的场景时同步更新可能导致主线程长时间占用。这也正是我在第五章要展开的信号“时序与完整性”问题。4.4 开发体验信号也不是没有代价信号框架的强项是性能直接、代码可预测但调试体验差异很大。虚拟DOM框架调试时看组件树就够了DOM节点从哪来一目了然。信号框架的依赖关系图藏在运行时普通DevTools里看不到排查“谁更新了这段UI”时你得靠框架自带的调试工具。Solid的DevTools、Vue的组件面板都能展示依赖追踪路径但用起来没有React DevTools那么无脑。我个人的体验是团队里只要有一两个人能讲清依赖收集原理信号框架的效率会远超虚拟DOM但如果整个团队都是一路“React式”开发思维走过来的学习曲线会很陡。选型不能只看benchmark团队认知成本和项目维护成本也得算进去。5. 信号系统的“信号完整性”问题借硬件思维破案这一节的标题用了热搜词里那些硬件术语是因为我发现前端信号系统里最隐蔽的几个坑和模拟电路里的信号混叠、采样重建、噪声问题有惊人的同构性。别误会这里不是讲硬件而是借它的概念帮你建立一个新的排查直觉。5.1 混叠失真批量更新里看不见的中间态硬件里的混叠是指采样频率不足时高频信号被伪装成低频信号。前端信号的混叠失真则表现为中间态被副作用观察到了。比如你连续修改一个状态的三个字段在虚拟DOM框架里render函数只会在整批更新结束后执行一次取到最终快照。但信号框架里如果每个字段的setter都立即触发依赖通知而中间又有人去读取这个状态那么一个“只应该看到结果”的effect就可能看到半成品中间态。这种问题在“跨模块协同更新”时尤其严重。例如A模块先设置了一个“加载中”标志位B模块则等待某个商品列表更新完成后再渲染价格。如果A和B直接订阅同一个信号对象很可能在列表还没完全就绪时B已经把中间态消费掉了。解决手段通常是框架自带的批量更新APISolid的batch、Vue的nextTick、Angular的untracked辅助函数把一组变更包成一个事务等到副作用时机统一执行。写代码的时候要养成习惯和计算属性相关的状态修改尽量放在同一个批量事务里。5.2 采样与重建调度器就是你的“采样器”虚拟DOM框架在调度策略上更接近“过采样”不管状态变了多少次以帧为单位统一做一次全量diff。信号框架则是“事件驱动”状态一变立刻精确更新延迟最低但更新次数可能更多。这里和“采样、抗混叠滤波与信号重建”很像——虚拟DOM用高成本过采样换平滑性信号用精准采样换延迟和资源消耗。实际开发中我建议对高频数据设置自己的“抗混叠滤波器”。最简单的方式是加一个节流信号原始信号高频变化但下游只订阅一个每100ms更新一次的派生信号。这样既保留信号系统的低延迟又不会让图表每秒重绘几十次。这个“手动重建”的思路本质上就是软著里的数字低通滤波。5.3 噪声与去噪生产环境里的信号抖动排查信号系统在生产环境最典型的问题是“抖动”一个状态没变但某段UI频繁更新CPU曲线呈锯齿状。最常见原因有三个一是在effect里读取了一个被其他effect频繁写入的信号形成反馈回路二是派生值没有缓存每次读取都重算导致本不该更新的订阅者被反复触发三是依赖收集越界——比如在effect里读取了一个全局单例状态而这个状态跟组件本身无关。排查这类问题的思路和硬件“信号完整性”很像先看发射端谁在写入状态再看传输通道依赖图有没有意外连接最后看接收端谁在读取状态读取时机是什么。只要在依赖追踪路径上找到意料之外的中间节点基本就锁定问题了。Solid的DevTools能展示effect的依赖树Vue的renderEffect日志能打印依赖列表Angular也有signal调试面板。不要在脑子里推直接用图说话。5.4 “多bit信号跨时钟域”的前端版跨帧状态同步前端同样存在“多个状态在不同时机更新但合到一起才构成一个合法快照”的场景。举个例子折线图同时展示温度和湿度两条曲线温度信号先到湿度信号后到如果渲染逻辑读温度时湿度还是旧值图例就会产生“错位帧”。这和硬件里跨时钟域同步问题非常像不同步的数据在合并时出现逻辑毛刺。我的处理经验是为这类跨信号组合创建聚合派生状态而不是让视图直接订阅多个独立信号。例如用createMemo把温度和湿度合并为一个“聚合数据对象”下游只有这一个数据源。这样无论两个信号如何先后变化视图永远只能看到聚合后的完整帧。6. 迁移路线图与常见问题速查聊这么多原理最后给真正要动干活的同学一套可落地的方案。很多人问“要不要把现在项目重写成信号框架”我的答案永远是先别急着重写先计算一下你项目的核心痛点是不是状态更新效率。如果你的页面是内容型低交互虚拟DOM那点性能开销根本无感知重写纯属自找麻烦。如果你的页面有高频表格、实时图表、协同编辑之类的模块那就按渐进式方案来。6.1 渐进式迁移策略四步走第一步在现有项目里找一个更新最频繁、性能最差的独立模块常见的是数据监控面板、表格组件单独用信号方案重构。React项目可以直接引入preact/signals在组件内部局部使用信号优化高频逻辑不动整个框架。Vue项目则直接用自带ref/computed写好这个模块Vapor模式已经能自动优化编译产物。第二步把模块对外接口设计为纯函数输入输出。模块内部用信号对外只暴露状态和回调让父组件感知不到信号的存在。这样万一这个模块后续要回退成本也极低。第三步评估模块的性能收益同时在代码评审里专门花一节课时间给团队讲信号机制。记住架构迁移最大的风险不是技术而是团队认知。第四步如果收益足够再考虑把信号机制推广到其他模块最终形成一套团队自己的响应式状态管理规范。这个过程可能持续两三个季度要留给开发同学充分踩坑的时间。6.2 常见问题排查速查表现象可能原因排查思路解决办法信号更新了UI不刷新视图订阅的是派生值但派生值没有被正确追踪检查派生值是否在高频变化的依赖里用DevTools追踪依赖图用batch包住多状态更新或直接订阅原始信号effect陷入死循环effect里读取并写入了同一组信号形成反馈回路打印effect依赖列表看是否有意外依赖把写入操作移到事件回调或untracked作用域异步更新丢失在异步回调里直接修改信号外部批量事务破坏了同步语义查看更新时序确认修改发生在异步微任务中用框架的批量API包裹异步回调或改用不可变快照对象SSR水合后内容不一致服务端和客户端首次渲染时对同一信号初始值不同检查信号初始化是否依赖浏览器APISSR阶段统一使用服务端快照作为信号初始值内存持续增长组件销毁时effect或computed没有完成订阅清理在DevTools的Memory面板里抓“Detached DOM”确保使用框架的onCleanup清理所有手动订阅高频数据导致渲染帧率下降下游UI直接订阅高频原始信号没有做采样/节流用Performance面板查看更新触发间隔增加派生节流信号低频采样后再渲染6.3 一个真实项目的迁移复盘去年我把一个工业数据大屏从虚拟DOM框架迁到信号方案这个项目有实时仪表盘、上百个传感器通道、每秒数据刷新原先滚动监控数据时经常卡到没法用。迁移范围只动了数据展示层业务逻辑全部保留。前期最痛苦的不是改代码而是团队成员始终想用“组件重渲染”的思维去套信号——一遇到数据不更新就习惯性去看shouldCompoentDidUpdate在哪里根本不存在那个概念了。后来我给团队做了一次三小时的分享专门讲清楚“谁读了信号谁就订阅了更新”这条核心原则代码产出才真正顺起来。迁移完成后最直观的变化是CPU占用从长期30%降到了个位数打包体积还小了约15%去掉了虚拟DOM运行时的开销。更重要的是从此这类的面板类新需求大家第一直觉不再是“加个定时器刷新”而是“让数据自己找到它该去的DOM节点”。这种思维方式上的变化比性能收益本身更值钱。我个人在实际操作中的体会是2026年的前端框架集体转向信号说到底是在为一个更复杂的交互时代做底层基础设施。这不是说虚拟DOM一无是处跨平台抽象、生态积累、行业心智这些东西短时间内无法替代。但如果你正在做一个对性能敏感的复杂应用或者你即将从零搭建一个长期演进的前端项目认真研究一下信号机制绝对值得。最后送大家一句实在话框架可以晚点跟风但领域里最核心的“为什么变了”这个问题早想清楚比晚想清楚好得多。