前端框架本质响应式原理、虚拟 DOM 与组件化思想——Vue、React、Svelte 底层机制全解析Easy Vibe 前端基础【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe本篇技术指南是 Easy VibeAI 原生产品构建者的第一门课程浏览器与前端附录中的核心理论章节回答一个根本性问题前端框架Vue、React、Svelte 等到底在做什么即使你只学过 HTML、CSS 和少量 JavaScript也能从零理解。读完本文你将彻底掌握数据驱动视图背后的三大支柱——响应式系统、虚拟 DOM、组件化思想并能解释三大框架在底层实现上的本质差异为后续在 初中级开发阶段 使用组件库、与 AI 协作编写前端代码打下坚实的理论基础。阅读前请确认你已了解两个前置概念如有不确定可先复习对应章节HTML网页的骨架定义页面上有哪些元素标题、段落、按钮、图片……见 HTML 与 CSS 布局。JavaScript让网页动起来的编程语言可以修改页面内容、响应用户操作见 JavaScript 深入指南。另外还有一个后续会反复出现的概念先在这里完整讲清楚。什么是 DOMDOM 的全称是Document Object Model文档对象模型。当你在浏览器中打开一个网页时浏览器做的第一件事是读取 HTML 代码。读取完成后浏览器并不会直接把 HTML 文本原样显示而是先把 HTML 代码转换成一棵树结构并存入内存这棵树就是 DOM 树。树上的每个节点Node对应 HTML 中的一个标签标签之间的嵌套关系在 DOM 树中体现为父节点与子节点。动手试试仓库中的交互演示 WhatIsDomDemo.vue 实现了鼠标悬停联动效果——左侧的 HTML 代码与右侧的 DOM 树节点互相高亮让你直观看到 HTML 的每一行都对应 DOM 树上的一个节点。为什么要理解 DOM因为 JavaScript 修改页面的方式正是操作这棵 DOM 树——增删节点、修改内容。而前端框架做的核心工作就是把这些 DOM 操作自动化。后面我们会反复使用DOM这个词理解 DOM 是理解框架原理的基石。0. 引入什么是前端框架先解释框架Framework一词。在编程中框架是已经写好的代码 规则的集合体它规定了你的代码应该如何组织、如何运行。你只需按照规则写自己的业务代码框架负责处理大量重复、繁琐的底层工作。前端框架则是专门帮助你构建网页界面的框架。目前最常用的有 Vue、React、Svelte、Angular 等。那么它具体解决了什么问题三张卡片概括了核心逻辑对应演示组件 FrameworkMotivationDemo.vue——接下来我们从最基本的问题开始一步步讲清楚。1. 核心问题数据变了画面怎么办1.1 先分清数据与画面任何 Web 应用里都始终存在两样东西数据Data / State程序内部保存的信息例如购物车里有 3 件商品用户名是山田太郎当前选中的是第 2 个标签页。这些数据存放在 JavaScript 变量里用户看不见。画面UI用户在屏幕上看到的东西例如页面上显示购物车(3)、欢迎山田太郎、第 2 个标签页高亮。这是 HTML 元素呈现的视觉效果。数据与画面之间存在对应关系数据是3 件商品画面就应显示3数据变成4 件商品画面也应跟着变成4。问题在于这个跟着变的过程由谁来负责动手试试交互演示 DataUIGapDemo.vue 用两个面板分别模拟数据左侧和画面右侧。点击添加商品观察左侧数据已变化但右侧画面未更新——两者被断开了此时必须点击同步画面手动修复。从该组件源码可以看到它分别用dataCount与uiCount两个独立的ref状态存储两侧数值再用一个computed判断dataCount.value ! uiCount.value来标记失步状态这恰好从代码层面复现了数据与视图天然分离的事实。1.2 为什么 JavaScript 变量变了画面不会自动变这是初学者最容易卡住的点我们按基础原理逐步拆解。在 JavaScript 中变量是存放数据的内存空间。当你执行count count 1时JavaScript 引擎做的事情非常简单把内存中 count 位置的值从 3 改成 4。操作结束就到此为止不会再发生任何事。而页面上显示的内容比如span3/span这个 DOM 节点存放在另一块完全独立的内存空间。引擎修改变量时完全不知道页面上有展示该变量值的 DOM 节点也没有任何机制去检查它。所以根本原因是JavaScript 变量与 DOM 节点是两块独立的内存二者之间不存在任何自动联动机制。修改变量只改变变量的内存对 DOM 节点的内存毫无影响。let count 3 // 页面上有一个展示 count 值的 DOM 节点 // span idcounter3/span count 4 // JavaScript 引擎做了什么 // → 把变量 count 内存中的值从 3 改成 4 // → 结束。仅此而已。 // 页面上的 span 依然显示 3若想让页面也显示4你必须额外写代码手动找到那个 DOM 节点并修改其内容count 4 // 第 1 步修改变量 // 第 2 步必须自己写——找到 DOM 节点把它的文本改成新值 document.getElementById(counter).textContent count如果页面上有 5 处展示 count 值的地方购物车数量、商品列表、总价、小计、状态栏你就得写 5 份这样的代码。漏掉任何一处那个位置就会一直显示旧值用户看到的便是错误信息。1.3 框架做了什么两步建立自动连接框架之所以能实现自动同步靠的是两步配合——缺一不可。第 1 步用模板登记变量要显示在哪里在框架的 HTML 模板中用{{ count }}这样的语法标记这里要显示 count 的值!-- Vue 模板 -- span购物车{{ count }} 件/span !-- 位置 A想显示 count -- span合计¥{{ count * 99 }}/span !-- 位置 B也用到 count -- span{{ count 5 ? 太多了 : 正常 }}/span !-- 位置 C也用到 count --框架首次渲染页面时会记录下这层登记关系位置 A、B、C 都依赖 count。第 2 步框架监听变量变更后查登记表自动更新框架借助 JavaScript 内置的Proxy代理把你的变量包一层变成被监听的变量。当你修改该变量时Proxy 在完成赋值的同时还会悄悄做另一件事通知框架count 变了。框架收到通知后查阅第 1 步的登记表把 A、B、C 三处全部更新。原生 JS 写 HTML → span idcounter3/span与变量毫无连接 改变量 → count 4 → 结束画面无反应 手动补救 → document.getElementById(counter).textContent 4 → 画面终于更新 Vue 框架 写模板 → span{{ count }}/span框架记住这里依赖 count 改变量 → count 4 → Proxy 拦截 → 通知框架 → 框架查登记表 → 自动更新 A/B/C这正是只有框架才能做到自动同步的原因——原生 HTML 的span与 JS 变量之间没有任何连接而框架的模板语法{{ }}正是建立这层连接的钥匙。你写下{{ count }}框架就知道这里要展示 count当 count 变化时它就能精确定位到这里并完成更新。动手试试WhyNoAutoSyncDemo.vue 让你在原生 JavaScript与使用框架两种模式间切换对比原生模式下变量变了画面纹丝不动必须手动逐条同步框架模式下变量一变框架自动完成所有步骤画面立刻跟上。1.4 对比手动同步 vs 自动同步的真实差距在理解了原理之后再看一个更复杂的场景体会两种方式的差距有多大。动手试试ManualVsAutoSyncDemo.vue 左侧是无框架的手动同步——每个显示区域都要单独点击同步按钮来更新右侧是有框架的自动同步——只需点击添加商品所有显示区域自动更新。你甚至可以在左侧故意漏同步一处看看会发生什么。这就是前端框架存在的根本原因赋予 JavaScript 变量变更时自动通知画面更新的能力消灭手动同步造成的遗漏与错误。2. 框架核心思想用数据描述画面2.1 两种写法的差异理解了自动同步的价值后再看看框架具体是如何实现的。在没有框架的时代例如 jQuery 时代代码是这样写的——你一步步告诉浏览器该做什么// 第 1 步找到页面上 id 为 counter 的元素 var element document.getElementById(counter) // 第 2 步把这个元素的文本内容改成新值 element.textContent 4 // 第 3 步找到另一个元素也改掉 document.getElementById(total).textContent ¥396 // 第 4 步如果数量大于 5还得改状态显示……这种写法叫命令型Imperative——你在命令浏览器一步步执行操作。有了框架之后代码变成这样——你只描述画面应该是什么样!-- 不关心这个值是如何被更新到页面上的 -- !-- 只说这里显示 count 的值 -- span{{ count }}/span span合计¥{{ count * 99 }}/span span v-ifcount 5商品太多了/span这种写法叫声明型Declarative——你声明画面的最终状态如何到达这个状态由框架处理。2.2 核心公式UI f(State)所有现代前端框架——无论 Vue、React 还是 Svelte——都遵循同一个核心思想可以用一个公式表达UI f(State)这个公式的含义是State状态你的应用数据即 JavaScript 里的变量。购物车有几件商品、用户是否登录、当前是哪个页面……f函数框架的渲染机制它知道如何把数据转换成画面。UI画面用户在屏幕上看到的最终结果。含义给定一份数据State经过框架的处理f就能确定地得到对应的画面UI。数据变了画面随之变化。开发者只需关心数据不必关心画面如何更新。动手试试DeclarativeFormulaDemo.vue 让你在左侧修改数据State观察右侧画面UI如何自动变化——这就是UI f(State)的直观呈现。2.3 为什么声明型优于命令型声明型写法的优势如下对比项命令型无框架声明型有框架代码量每次更新都要写具体操作代码模板只写一次框架自动处理出错率容易漏更新某处框架保证所有位置都被更新可读性大量 DOM 操作混在代码中代码清晰描述画面结构维护成本改一个功能要动很多地方只改数据逻辑画面自动跟随总而言之声明型让你把精力集中在业务逻辑数据如何变化上把你从画面如何更新这种重复且易错的工作中解放出来。3. 响应式系统框架如何得知数据变化3.1 什么是响应式前面说到的数据变化 → 画面自动更新这里藏着一个技术难题JavaScript 本身不具备变量被修改时自动通知别人的能力。你写count 4JavaScript 只是把 count 的值从 3 改成 4不会自动通知任何人。框架必须有一种机制来发现你改了数据。响应式Reactivity就是这类机制的总称当数据变化时系统能自动感知该变化并执行相应的更新操作。3.2 三种不同的实现方式不同框架采用了不同的技术路线来实现响应式——这也是 Vue、React、Svelte 之间最根本的差异。方式 1代理拦截Vue 的做法Vue 使用 JavaScript 内置的Proxy代理机制。Proxy可以在你读取或修改对象属性时自动执行指定的代码。Vue 把数据对象用Proxy包起来。当你执行count 4时Proxy拦截这次写入操作通知 Vue count 的值变了随后 Vue 更新所有用到 count 的画面部分。作为开发者无需任何额外操作——直接赋值Vue 自动感知。方式 2显式调用React 的做法React 不使用Proxy而是要求你在修改数据时通过专用函数// React 的写法 const [count, setCount] useState(0) // 不能直接写 count 4React 感知不到 // 必须调用 setCount setCount(4)只有当你调用setCount()时React 才知道数据变了并更新画面。如果直接写count 4React 完全无感知画面不会更新。这种方式更显式——所有数据变化都是你主动告知框架的不会发生非预期的更新。方式 3编译器分析Svelte 的做法Svelte 采用了完全不同的路线。Svelte 有一个编译器Compiler在代码运行之前编译器会先分析源代码。当编译器发现count 1这类赋值语句时会在这行代码后面自动插入通知画面更新的代码。也就是说当代码真正运行时通知这个动作早已被编译器预埋好了。你的代码看起来就是普通的 JavaScript 赋值但编译后的代码里已经加入了画面更新逻辑。动手试试ReactivityMechanismDemo.vue 让你切换不同框架的标签页点击修改数据观察各框架在引擎盖下经历了哪些步骤来检测数据变化并更新画面。3.3 三种方式的对比对比项VueProxy 代理React显式调用Svelte编译器开发者的写法直接赋值count 4必须使用setCount(4)直接赋值count 4感知变化的时机运行时自动拦截开发者主动通知编译时预插入通知代码运行时的性能开销Proxy 拦截略有开销setState 调度略有开销几乎零额外开销调试难度中等数据流清晰、相对容易需要理解编译后的代码适合场景追求开发效率与自然写法追求可预测的数据流追求极致运行性能三种方式没有绝对优劣Vue 写起来最自然React 数据流最可控Svelte 运行时性能最高。选哪个取决于项目的具体需求。4. 组件把画面拆成可复用的小积木4.1 为什么要拆分一个完整的网页可能包含导航栏、侧边栏、内容区、搜索框、用户头像、各种按钮……如果把所有代码写进一个文件文件会变得极长维护非常困难。组件Component就是把画面拆分成独立的小块每一块管理自己的数据、自己的画面、自己的逻辑。例如一个电商页面可以拆成这些组件NavBar组件负责顶部导航栏SearchBox组件负责搜索框ProductCard组件负责单个商品卡片ShoppingCart组件负责购物车每个组件相互独立。ProductCard无需知道NavBar内部写了什么代码只需管好自己。4.2 组件的三大优点优点 1复用。写一个ProductCard组件就能在页面上用 100 次——每次传入不同的商品数据渲染出不同的商品卡片而不必复制粘贴 100 份 HTML 代码。优点 2封装。组件内部的数据和逻辑相互独立。修改SearchBox组件的代码不会影响ProductCard。多人协作时不同的人可以同时开发不同的组件而互不干扰。优点 3可维护。某个功能出问题时直接找到对应组件修改即可不用在几千行的大文件里翻找。动手试试ComponentTreeDemo.vue 让你点击左侧组件名查看页面上对应的区域特别注意同一个ProductCard组件被多次复用每次都显示不同数据。4.3 组件在代码里长什么样以 Vue 为例一个组件就是一个.vue文件包含三部分!-- ProductCard.vue -- template !-- 这里写 HTML 结构 —— 组件的长相 -- div classcard h3{{ name }}/h3 p价格¥{{ price }}/p button clickaddToCart加入购物车/button /div /template script setup // 这里写 JavaScript 逻辑 —— 组件的行为 const props defineProps([name, price]) function addToCart() { // 处理加入购物车的逻辑 } /script style scoped /* 这里写 CSS 样式 —— 组件的装饰 */ .card { border: 1px solid #ccc; padding: 16px; } /style使用该组件时就像使用一个自定义 HTML 标签!-- 在其他地方使用 ProductCard 组件 -- ProductCard name无线耳机 price299 / ProductCard name机械键盘 price599 / ProductCard name显示器 price1999 /仅 3 行代码就渲染出 3 张不同的商品卡片。这一组件化思想在本仓库中也有充分体现Easy Vibe 课程站本身的界面就是由数十个 Vue 组件拼装而成的见 docs/.vitepress/theme/components 目录例如课程导航卡片 NavCard.vue、网格布局 NavGrid.vue而本文提到的 11 个交互演示也各自是一个独立的.vue组件如 WhatIsDomDemo.vue。在 初中级开发的组件库课程 中你还会学到如何直接拼积木式地使用现成组件库。5. DOM 操作的代价框架为何如此大费周章5.1 什么是 DOM 操作如前所述DOM 是浏览器解析 HTML 后生成的树结构。DOM 操作就是用 JavaScript 修改这棵树上的节点例如改文本、增删元素、改样式。这些操作本身并不复杂但浏览器在执行 DOM 操作后为了刷新屏幕上的显示还要做大量额外工作样式重算这个节点及其子节点的 CSS 样式需要变吗重排/回流Layout / Reflow需要重新计算页面上所有元素的位置和尺寸——因为一个元素的改动可能影响其他元素的位置。重绘Paint把计算好的内容绘制到屏幕上。这 3 步每一步都有计算成本。如果代码频繁触发 DOM 操作浏览器就要反复执行这些步骤页面就会变卡。动手试试DomOperationCostDemo.vue 对比逐个直接操作 DOM与一次性批量操作 DOM的耗时。随着修改次数增多逐个操作的耗时急剧上升。5.2 框架如何解决这个问题既然直接操作 DOM 代价高框架便想方设法减少 DOM 操作次数。具体有两大策略策略 1虚拟 DOM 差分对比Vue、React 的做法虚拟 DOMVirtual DOM是一个 JavaScript 对象结构与真实 DOM 树一一对应但只存在于内存中不会触发浏览器的布局与绘制。数据变化时框架的处理流程是用 JavaScript 对象创建一棵新的虚拟 DOM 树描述数据变化后的画面把新树与旧树做比较这个过程叫Diff即差分对比找出哪些节点变了只把真正变化的部分应用到真实 DOM这个过程叫Patch即打补丁这样一来无论数据怎么变最终对真实 DOM 的操作始终是最小化的。动手试试VirtualDomDiffDemo.vue 让你点击修改数据观察虚拟 DOM 如何比较新旧两棵树、找出变化节点注意最右侧的真实 DOM——只有真正变化的部分才会闪烁。策略 2编译期精确定位Svelte 的做法Svelte 不使用虚拟 DOM。它的编译器在你写代码时就已完成分析——当 count 变化时需要更新第 3 行的span元素。运行时直接定位并更新那个元素完全不需要比较新旧两棵树。这种做法跳过了 Diff 步骤理论上性能更优。但它依赖编译器的分析能力——如果编译器不够聪明就无法精确定位所有需要更新的位置。6. 运行时 vs 编译时框架设计的核心权衡6.1 两个阶段前端代码从你写完到最终在浏览器中运行要经历两个阶段编译时Compile-time / Build-time你的源代码被构建工具Vite、Webpack 等处理转换成浏览器能直接运行的代码。这个过程发生你的电脑上在用户打开页面前完成。运行时Runtime转换后的代码在用户的浏览器中执行。框架的核心逻辑虚拟 DOM 的 Diff、响应式的追踪等都在这个阶段运转。6.2 两个阶段里框架的分工不同框架在两个阶段投入的工作量不同这决定了它们的性能特性和包体积React大部分工作在运行时完成。虚拟 DOM 的创建、Diff、Patch 都发生在浏览器里。优点是灵活性高代价是必须把整套框架运行时代码约 40KB发送给浏览器。Vue混合方式。模板在编译时被优化编译器会标记静态不变节点但最终的画面更新仍由运行时的虚拟 DOM 完成。运行时代码约 30KB。Svelte大部分工作在编译时完成。编译器分析你的代码直接生成精确的 DOM 更新指令。运行时几乎不含框架代码——最终打包产物里只有你自己的业务代码包体积最小。动手试试FrameworkSpectrumDemo.vue 让你点击不同框架的标签页查看它们在运行时 ↔ 编译时光谱上的位置以及在包体积、运行性能、开发体验上的各自取舍。6.3 行业趋势近年框架的发展方向非常明确尽量把工作从运行时搬到编译时——因为编译时的计算不消耗用户设备资源不影响页面加载速度。Vue正在开发 Vapor Mode目标是跳过虚拟 DOM在编译时直接生成 DOM 操作代码React发布了 React Compiler在编译时自动优化组件的重渲染行为Svelte 5引入 Runes 系统进一步增强编译时的分析能力这部分内容与另一篇附录 前端框架入门框架对比 互为补充那篇从技术演进史的角度讲述框架为何不断进化本篇则深入框架内部机制。7. 总结回顾本文的核心要点前端框架解决的根本问题应用内数据变化时自动、高效、可靠地更新画面让开发者不再手动操作 DOM。所有框架共同遵循的核心思想UI f(State)——画面是数据的函数开发者只需关注数据变化框架负责把数据变化反映到画面。框架之间的技术差异技术点含义响应式系统框架检测数据变化的方式Vue 用 Proxy 拦截React 用显式 setStateSvelte 用编译器分析。虚拟 DOMVue 和 React 用 JavaScript 对象模拟 DOM 树通过新旧两棵树比较Diff找出最小更新量减少真实 DOM 操作。组件化把画面拆分成独立、可复用的积木每个组件管理自己的数据与画面。编译时优化在构建阶段提前分析与优化减少运行时计算量。Svelte 在这条路上走得最远。一句话概括前端框架的本质工作就是接下从数据到画面的同步过程让开发者只思考数据的逻辑而不再手动操作画面。术语对照表英文术语中文译名说明Framework框架预先写好的代码与规则的集合为开发者提供应用的基础结构与通用能力。DOM文档对象模型浏览器解析 HTML 后生成的树状数据结构JavaScript 通过操作它来修改页面。Virtual DOM虚拟 DOM用 JavaScript 对象模拟 DOM 树通过 Diff 算法找出最小更新路径减少真实 DOM 操作次数。State状态应用中的数据如用户信息、购物车内容、页面当前状态等。Reactivity响应式数据变化时系统自动感知并执行相应画面更新的机制。Proxy代理JavaScript 内置机制可拦截对象的读写操作。Vue 3 用它实现响应式。Component组件独立、可复用的画面代码块包含自己的 HTML 结构、JavaScript 逻辑和 CSS 样式。Declarative声明型一种编程方式你描述最终想要什么如何实现由框架决定。Imperative命令型一种编程方式你一步步告诉程序具体怎么做。Diff差分对比比较新旧两棵虚拟 DOM 树找出哪些节点发生了变化。Patch补丁应用把 Diff 发现的差异应用到真实 DOM 上。Compile-time编译时代码在构建阶段被处理的时期发生在用户打开页面之前。Runtime运行时代码在用户浏览器中执行的时期。Compiler编译器把源代码转换成另一种形式代码的程序。Svelte 的编译器把.svelte文件转换成高效的 JavaScript。【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 前端框架本质：响应式原理、虚拟 DOM 与组件化思想——Vue、React、Svelte 底层机制全解析（Easy Vibe 前端基础）
前端框架本质响应式原理、虚拟 DOM 与组件化思想——Vue、React、Svelte 底层机制全解析Easy Vibe 前端基础【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe本篇技术指南是 Easy VibeAI 原生产品构建者的第一门课程浏览器与前端附录中的核心理论章节回答一个根本性问题前端框架Vue、React、Svelte 等到底在做什么即使你只学过 HTML、CSS 和少量 JavaScript也能从零理解。读完本文你将彻底掌握数据驱动视图背后的三大支柱——响应式系统、虚拟 DOM、组件化思想并能解释三大框架在底层实现上的本质差异为后续在 初中级开发阶段 使用组件库、与 AI 协作编写前端代码打下坚实的理论基础。阅读前请确认你已了解两个前置概念如有不确定可先复习对应章节HTML网页的骨架定义页面上有哪些元素标题、段落、按钮、图片……见 HTML 与 CSS 布局。JavaScript让网页动起来的编程语言可以修改页面内容、响应用户操作见 JavaScript 深入指南。另外还有一个后续会反复出现的概念先在这里完整讲清楚。什么是 DOMDOM 的全称是Document Object Model文档对象模型。当你在浏览器中打开一个网页时浏览器做的第一件事是读取 HTML 代码。读取完成后浏览器并不会直接把 HTML 文本原样显示而是先把 HTML 代码转换成一棵树结构并存入内存这棵树就是 DOM 树。树上的每个节点Node对应 HTML 中的一个标签标签之间的嵌套关系在 DOM 树中体现为父节点与子节点。动手试试仓库中的交互演示 WhatIsDomDemo.vue 实现了鼠标悬停联动效果——左侧的 HTML 代码与右侧的 DOM 树节点互相高亮让你直观看到 HTML 的每一行都对应 DOM 树上的一个节点。为什么要理解 DOM因为 JavaScript 修改页面的方式正是操作这棵 DOM 树——增删节点、修改内容。而前端框架做的核心工作就是把这些 DOM 操作自动化。后面我们会反复使用DOM这个词理解 DOM 是理解框架原理的基石。0. 引入什么是前端框架先解释框架Framework一词。在编程中框架是已经写好的代码 规则的集合体它规定了你的代码应该如何组织、如何运行。你只需按照规则写自己的业务代码框架负责处理大量重复、繁琐的底层工作。前端框架则是专门帮助你构建网页界面的框架。目前最常用的有 Vue、React、Svelte、Angular 等。那么它具体解决了什么问题三张卡片概括了核心逻辑对应演示组件 FrameworkMotivationDemo.vue——接下来我们从最基本的问题开始一步步讲清楚。1. 核心问题数据变了画面怎么办1.1 先分清数据与画面任何 Web 应用里都始终存在两样东西数据Data / State程序内部保存的信息例如购物车里有 3 件商品用户名是山田太郎当前选中的是第 2 个标签页。这些数据存放在 JavaScript 变量里用户看不见。画面UI用户在屏幕上看到的东西例如页面上显示购物车(3)、欢迎山田太郎、第 2 个标签页高亮。这是 HTML 元素呈现的视觉效果。数据与画面之间存在对应关系数据是3 件商品画面就应显示3数据变成4 件商品画面也应跟着变成4。问题在于这个跟着变的过程由谁来负责动手试试交互演示 DataUIGapDemo.vue 用两个面板分别模拟数据左侧和画面右侧。点击添加商品观察左侧数据已变化但右侧画面未更新——两者被断开了此时必须点击同步画面手动修复。从该组件源码可以看到它分别用dataCount与uiCount两个独立的ref状态存储两侧数值再用一个computed判断dataCount.value ! uiCount.value来标记失步状态这恰好从代码层面复现了数据与视图天然分离的事实。1.2 为什么 JavaScript 变量变了画面不会自动变这是初学者最容易卡住的点我们按基础原理逐步拆解。在 JavaScript 中变量是存放数据的内存空间。当你执行count count 1时JavaScript 引擎做的事情非常简单把内存中 count 位置的值从 3 改成 4。操作结束就到此为止不会再发生任何事。而页面上显示的内容比如span3/span这个 DOM 节点存放在另一块完全独立的内存空间。引擎修改变量时完全不知道页面上有展示该变量值的 DOM 节点也没有任何机制去检查它。所以根本原因是JavaScript 变量与 DOM 节点是两块独立的内存二者之间不存在任何自动联动机制。修改变量只改变变量的内存对 DOM 节点的内存毫无影响。let count 3 // 页面上有一个展示 count 值的 DOM 节点 // span idcounter3/span count 4 // JavaScript 引擎做了什么 // → 把变量 count 内存中的值从 3 改成 4 // → 结束。仅此而已。 // 页面上的 span 依然显示 3若想让页面也显示4你必须额外写代码手动找到那个 DOM 节点并修改其内容count 4 // 第 1 步修改变量 // 第 2 步必须自己写——找到 DOM 节点把它的文本改成新值 document.getElementById(counter).textContent count如果页面上有 5 处展示 count 值的地方购物车数量、商品列表、总价、小计、状态栏你就得写 5 份这样的代码。漏掉任何一处那个位置就会一直显示旧值用户看到的便是错误信息。1.3 框架做了什么两步建立自动连接框架之所以能实现自动同步靠的是两步配合——缺一不可。第 1 步用模板登记变量要显示在哪里在框架的 HTML 模板中用{{ count }}这样的语法标记这里要显示 count 的值!-- Vue 模板 -- span购物车{{ count }} 件/span !-- 位置 A想显示 count -- span合计¥{{ count * 99 }}/span !-- 位置 B也用到 count -- span{{ count 5 ? 太多了 : 正常 }}/span !-- 位置 C也用到 count --框架首次渲染页面时会记录下这层登记关系位置 A、B、C 都依赖 count。第 2 步框架监听变量变更后查登记表自动更新框架借助 JavaScript 内置的Proxy代理把你的变量包一层变成被监听的变量。当你修改该变量时Proxy 在完成赋值的同时还会悄悄做另一件事通知框架count 变了。框架收到通知后查阅第 1 步的登记表把 A、B、C 三处全部更新。原生 JS 写 HTML → span idcounter3/span与变量毫无连接 改变量 → count 4 → 结束画面无反应 手动补救 → document.getElementById(counter).textContent 4 → 画面终于更新 Vue 框架 写模板 → span{{ count }}/span框架记住这里依赖 count 改变量 → count 4 → Proxy 拦截 → 通知框架 → 框架查登记表 → 自动更新 A/B/C这正是只有框架才能做到自动同步的原因——原生 HTML 的span与 JS 变量之间没有任何连接而框架的模板语法{{ }}正是建立这层连接的钥匙。你写下{{ count }}框架就知道这里要展示 count当 count 变化时它就能精确定位到这里并完成更新。动手试试WhyNoAutoSyncDemo.vue 让你在原生 JavaScript与使用框架两种模式间切换对比原生模式下变量变了画面纹丝不动必须手动逐条同步框架模式下变量一变框架自动完成所有步骤画面立刻跟上。1.4 对比手动同步 vs 自动同步的真实差距在理解了原理之后再看一个更复杂的场景体会两种方式的差距有多大。动手试试ManualVsAutoSyncDemo.vue 左侧是无框架的手动同步——每个显示区域都要单独点击同步按钮来更新右侧是有框架的自动同步——只需点击添加商品所有显示区域自动更新。你甚至可以在左侧故意漏同步一处看看会发生什么。这就是前端框架存在的根本原因赋予 JavaScript 变量变更时自动通知画面更新的能力消灭手动同步造成的遗漏与错误。2. 框架核心思想用数据描述画面2.1 两种写法的差异理解了自动同步的价值后再看看框架具体是如何实现的。在没有框架的时代例如 jQuery 时代代码是这样写的——你一步步告诉浏览器该做什么// 第 1 步找到页面上 id 为 counter 的元素 var element document.getElementById(counter) // 第 2 步把这个元素的文本内容改成新值 element.textContent 4 // 第 3 步找到另一个元素也改掉 document.getElementById(total).textContent ¥396 // 第 4 步如果数量大于 5还得改状态显示……这种写法叫命令型Imperative——你在命令浏览器一步步执行操作。有了框架之后代码变成这样——你只描述画面应该是什么样!-- 不关心这个值是如何被更新到页面上的 -- !-- 只说这里显示 count 的值 -- span{{ count }}/span span合计¥{{ count * 99 }}/span span v-ifcount 5商品太多了/span这种写法叫声明型Declarative——你声明画面的最终状态如何到达这个状态由框架处理。2.2 核心公式UI f(State)所有现代前端框架——无论 Vue、React 还是 Svelte——都遵循同一个核心思想可以用一个公式表达UI f(State)这个公式的含义是State状态你的应用数据即 JavaScript 里的变量。购物车有几件商品、用户是否登录、当前是哪个页面……f函数框架的渲染机制它知道如何把数据转换成画面。UI画面用户在屏幕上看到的最终结果。含义给定一份数据State经过框架的处理f就能确定地得到对应的画面UI。数据变了画面随之变化。开发者只需关心数据不必关心画面如何更新。动手试试DeclarativeFormulaDemo.vue 让你在左侧修改数据State观察右侧画面UI如何自动变化——这就是UI f(State)的直观呈现。2.3 为什么声明型优于命令型声明型写法的优势如下对比项命令型无框架声明型有框架代码量每次更新都要写具体操作代码模板只写一次框架自动处理出错率容易漏更新某处框架保证所有位置都被更新可读性大量 DOM 操作混在代码中代码清晰描述画面结构维护成本改一个功能要动很多地方只改数据逻辑画面自动跟随总而言之声明型让你把精力集中在业务逻辑数据如何变化上把你从画面如何更新这种重复且易错的工作中解放出来。3. 响应式系统框架如何得知数据变化3.1 什么是响应式前面说到的数据变化 → 画面自动更新这里藏着一个技术难题JavaScript 本身不具备变量被修改时自动通知别人的能力。你写count 4JavaScript 只是把 count 的值从 3 改成 4不会自动通知任何人。框架必须有一种机制来发现你改了数据。响应式Reactivity就是这类机制的总称当数据变化时系统能自动感知该变化并执行相应的更新操作。3.2 三种不同的实现方式不同框架采用了不同的技术路线来实现响应式——这也是 Vue、React、Svelte 之间最根本的差异。方式 1代理拦截Vue 的做法Vue 使用 JavaScript 内置的Proxy代理机制。Proxy可以在你读取或修改对象属性时自动执行指定的代码。Vue 把数据对象用Proxy包起来。当你执行count 4时Proxy拦截这次写入操作通知 Vue count 的值变了随后 Vue 更新所有用到 count 的画面部分。作为开发者无需任何额外操作——直接赋值Vue 自动感知。方式 2显式调用React 的做法React 不使用Proxy而是要求你在修改数据时通过专用函数// React 的写法 const [count, setCount] useState(0) // 不能直接写 count 4React 感知不到 // 必须调用 setCount setCount(4)只有当你调用setCount()时React 才知道数据变了并更新画面。如果直接写count 4React 完全无感知画面不会更新。这种方式更显式——所有数据变化都是你主动告知框架的不会发生非预期的更新。方式 3编译器分析Svelte 的做法Svelte 采用了完全不同的路线。Svelte 有一个编译器Compiler在代码运行之前编译器会先分析源代码。当编译器发现count 1这类赋值语句时会在这行代码后面自动插入通知画面更新的代码。也就是说当代码真正运行时通知这个动作早已被编译器预埋好了。你的代码看起来就是普通的 JavaScript 赋值但编译后的代码里已经加入了画面更新逻辑。动手试试ReactivityMechanismDemo.vue 让你切换不同框架的标签页点击修改数据观察各框架在引擎盖下经历了哪些步骤来检测数据变化并更新画面。3.3 三种方式的对比对比项VueProxy 代理React显式调用Svelte编译器开发者的写法直接赋值count 4必须使用setCount(4)直接赋值count 4感知变化的时机运行时自动拦截开发者主动通知编译时预插入通知代码运行时的性能开销Proxy 拦截略有开销setState 调度略有开销几乎零额外开销调试难度中等数据流清晰、相对容易需要理解编译后的代码适合场景追求开发效率与自然写法追求可预测的数据流追求极致运行性能三种方式没有绝对优劣Vue 写起来最自然React 数据流最可控Svelte 运行时性能最高。选哪个取决于项目的具体需求。4. 组件把画面拆成可复用的小积木4.1 为什么要拆分一个完整的网页可能包含导航栏、侧边栏、内容区、搜索框、用户头像、各种按钮……如果把所有代码写进一个文件文件会变得极长维护非常困难。组件Component就是把画面拆分成独立的小块每一块管理自己的数据、自己的画面、自己的逻辑。例如一个电商页面可以拆成这些组件NavBar组件负责顶部导航栏SearchBox组件负责搜索框ProductCard组件负责单个商品卡片ShoppingCart组件负责购物车每个组件相互独立。ProductCard无需知道NavBar内部写了什么代码只需管好自己。4.2 组件的三大优点优点 1复用。写一个ProductCard组件就能在页面上用 100 次——每次传入不同的商品数据渲染出不同的商品卡片而不必复制粘贴 100 份 HTML 代码。优点 2封装。组件内部的数据和逻辑相互独立。修改SearchBox组件的代码不会影响ProductCard。多人协作时不同的人可以同时开发不同的组件而互不干扰。优点 3可维护。某个功能出问题时直接找到对应组件修改即可不用在几千行的大文件里翻找。动手试试ComponentTreeDemo.vue 让你点击左侧组件名查看页面上对应的区域特别注意同一个ProductCard组件被多次复用每次都显示不同数据。4.3 组件在代码里长什么样以 Vue 为例一个组件就是一个.vue文件包含三部分!-- ProductCard.vue -- template !-- 这里写 HTML 结构 —— 组件的长相 -- div classcard h3{{ name }}/h3 p价格¥{{ price }}/p button clickaddToCart加入购物车/button /div /template script setup // 这里写 JavaScript 逻辑 —— 组件的行为 const props defineProps([name, price]) function addToCart() { // 处理加入购物车的逻辑 } /script style scoped /* 这里写 CSS 样式 —— 组件的装饰 */ .card { border: 1px solid #ccc; padding: 16px; } /style使用该组件时就像使用一个自定义 HTML 标签!-- 在其他地方使用 ProductCard 组件 -- ProductCard name无线耳机 price299 / ProductCard name机械键盘 price599 / ProductCard name显示器 price1999 /仅 3 行代码就渲染出 3 张不同的商品卡片。这一组件化思想在本仓库中也有充分体现Easy Vibe 课程站本身的界面就是由数十个 Vue 组件拼装而成的见 docs/.vitepress/theme/components 目录例如课程导航卡片 NavCard.vue、网格布局 NavGrid.vue而本文提到的 11 个交互演示也各自是一个独立的.vue组件如 WhatIsDomDemo.vue。在 初中级开发的组件库课程 中你还会学到如何直接拼积木式地使用现成组件库。5. DOM 操作的代价框架为何如此大费周章5.1 什么是 DOM 操作如前所述DOM 是浏览器解析 HTML 后生成的树结构。DOM 操作就是用 JavaScript 修改这棵树上的节点例如改文本、增删元素、改样式。这些操作本身并不复杂但浏览器在执行 DOM 操作后为了刷新屏幕上的显示还要做大量额外工作样式重算这个节点及其子节点的 CSS 样式需要变吗重排/回流Layout / Reflow需要重新计算页面上所有元素的位置和尺寸——因为一个元素的改动可能影响其他元素的位置。重绘Paint把计算好的内容绘制到屏幕上。这 3 步每一步都有计算成本。如果代码频繁触发 DOM 操作浏览器就要反复执行这些步骤页面就会变卡。动手试试DomOperationCostDemo.vue 对比逐个直接操作 DOM与一次性批量操作 DOM的耗时。随着修改次数增多逐个操作的耗时急剧上升。5.2 框架如何解决这个问题既然直接操作 DOM 代价高框架便想方设法减少 DOM 操作次数。具体有两大策略策略 1虚拟 DOM 差分对比Vue、React 的做法虚拟 DOMVirtual DOM是一个 JavaScript 对象结构与真实 DOM 树一一对应但只存在于内存中不会触发浏览器的布局与绘制。数据变化时框架的处理流程是用 JavaScript 对象创建一棵新的虚拟 DOM 树描述数据变化后的画面把新树与旧树做比较这个过程叫Diff即差分对比找出哪些节点变了只把真正变化的部分应用到真实 DOM这个过程叫Patch即打补丁这样一来无论数据怎么变最终对真实 DOM 的操作始终是最小化的。动手试试VirtualDomDiffDemo.vue 让你点击修改数据观察虚拟 DOM 如何比较新旧两棵树、找出变化节点注意最右侧的真实 DOM——只有真正变化的部分才会闪烁。策略 2编译期精确定位Svelte 的做法Svelte 不使用虚拟 DOM。它的编译器在你写代码时就已完成分析——当 count 变化时需要更新第 3 行的span元素。运行时直接定位并更新那个元素完全不需要比较新旧两棵树。这种做法跳过了 Diff 步骤理论上性能更优。但它依赖编译器的分析能力——如果编译器不够聪明就无法精确定位所有需要更新的位置。6. 运行时 vs 编译时框架设计的核心权衡6.1 两个阶段前端代码从你写完到最终在浏览器中运行要经历两个阶段编译时Compile-time / Build-time你的源代码被构建工具Vite、Webpack 等处理转换成浏览器能直接运行的代码。这个过程发生你的电脑上在用户打开页面前完成。运行时Runtime转换后的代码在用户的浏览器中执行。框架的核心逻辑虚拟 DOM 的 Diff、响应式的追踪等都在这个阶段运转。6.2 两个阶段里框架的分工不同框架在两个阶段投入的工作量不同这决定了它们的性能特性和包体积React大部分工作在运行时完成。虚拟 DOM 的创建、Diff、Patch 都发生在浏览器里。优点是灵活性高代价是必须把整套框架运行时代码约 40KB发送给浏览器。Vue混合方式。模板在编译时被优化编译器会标记静态不变节点但最终的画面更新仍由运行时的虚拟 DOM 完成。运行时代码约 30KB。Svelte大部分工作在编译时完成。编译器分析你的代码直接生成精确的 DOM 更新指令。运行时几乎不含框架代码——最终打包产物里只有你自己的业务代码包体积最小。动手试试FrameworkSpectrumDemo.vue 让你点击不同框架的标签页查看它们在运行时 ↔ 编译时光谱上的位置以及在包体积、运行性能、开发体验上的各自取舍。6.3 行业趋势近年框架的发展方向非常明确尽量把工作从运行时搬到编译时——因为编译时的计算不消耗用户设备资源不影响页面加载速度。Vue正在开发 Vapor Mode目标是跳过虚拟 DOM在编译时直接生成 DOM 操作代码React发布了 React Compiler在编译时自动优化组件的重渲染行为Svelte 5引入 Runes 系统进一步增强编译时的分析能力这部分内容与另一篇附录 前端框架入门框架对比 互为补充那篇从技术演进史的角度讲述框架为何不断进化本篇则深入框架内部机制。7. 总结回顾本文的核心要点前端框架解决的根本问题应用内数据变化时自动、高效、可靠地更新画面让开发者不再手动操作 DOM。所有框架共同遵循的核心思想UI f(State)——画面是数据的函数开发者只需关注数据变化框架负责把数据变化反映到画面。框架之间的技术差异技术点含义响应式系统框架检测数据变化的方式Vue 用 Proxy 拦截React 用显式 setStateSvelte 用编译器分析。虚拟 DOMVue 和 React 用 JavaScript 对象模拟 DOM 树通过新旧两棵树比较Diff找出最小更新量减少真实 DOM 操作。组件化把画面拆分成独立、可复用的积木每个组件管理自己的数据与画面。编译时优化在构建阶段提前分析与优化减少运行时计算量。Svelte 在这条路上走得最远。一句话概括前端框架的本质工作就是接下从数据到画面的同步过程让开发者只思考数据的逻辑而不再手动操作画面。术语对照表英文术语中文译名说明Framework框架预先写好的代码与规则的集合为开发者提供应用的基础结构与通用能力。DOM文档对象模型浏览器解析 HTML 后生成的树状数据结构JavaScript 通过操作它来修改页面。Virtual DOM虚拟 DOM用 JavaScript 对象模拟 DOM 树通过 Diff 算法找出最小更新路径减少真实 DOM 操作次数。State状态应用中的数据如用户信息、购物车内容、页面当前状态等。Reactivity响应式数据变化时系统自动感知并执行相应画面更新的机制。Proxy代理JavaScript 内置机制可拦截对象的读写操作。Vue 3 用它实现响应式。Component组件独立、可复用的画面代码块包含自己的 HTML 结构、JavaScript 逻辑和 CSS 样式。Declarative声明型一种编程方式你描述最终想要什么如何实现由框架决定。Imperative命令型一种编程方式你一步步告诉程序具体怎么做。Diff差分对比比较新旧两棵虚拟 DOM 树找出哪些节点发生了变化。Patch补丁应用把 Diff 发现的差异应用到真实 DOM 上。Compile-time编译时代码在构建阶段被处理的时期发生在用户打开页面之前。Runtime运行时代码在用户浏览器中执行的时期。Compiler编译器把源代码转换成另一种形式代码的程序。Svelte 的编译器把.svelte文件转换成高效的 JavaScript。【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考