eact需要调用setState方法，而vue直接修改变量就行。看起来只是两个框架的用法不同罢了，但响应式原理正在于此。

    从底层实现来看修改数据：在react中，组件的状态是不能被修改的，setState没有修改原来那块内存中的变量，而是去新开辟一块内存；
    而vue则是直接修改保存状态的那块原始内存。

    所以经常能看到react相关的文章里经常会出现一个词”immutable”，翻译过来就是不可变的。

    数据修改了，接下来要解决视图的更新：react中，调用setState方法后，会自顶向下重新渲染组件，自顶向下的含义是，该组件以及它的子组件全部需要渲染；而vue使用Object.defineProperty（vue@3迁移到了Proxy）对数据的设置（setter）和获取（getter）做了劫持，也就是说，vue能准确知道视图模版中哪一块用到了这个数据，并且在这个数据修改时，告诉这个视图，你需要重新渲染了。

    所以当一个数据改变，react的组件渲染是很消耗性能的——父组件的状态更新了，所有的子组件得跟着一起渲染，它不能像vue一样，精确到当前组件的粒度。
    https://blog.csdn.net/frontend_nian/article/details/123647481
    image.png

    翻译自Vuejs issue中尤大的回答：原文地址
    在Web应用程序中，丢帧（janky）更新通常是由于同步的高CPU时间和原生DOM的更新造成的。
    时间切片是在CPU工作期间保持应用响应的一种尝试，但它只影响CPU工作。DOM的刷新必须是同步的，以确保最终DOM状态的一致性。
    所以，想象两种丢帧更新的场景：

    1. CPU工作时间在16ms以内，但是需要操作大量的原生DOM更新操作（例如，挂在大量新的DOM内容）。不管你有没有使用时间切片，应用依旧会感觉到掉帧。
    2. CPU任务非常繁重，需要超过16ms的时间。从理论上讲，时间切片开始发挥作用了。然而，HCI的研究表明，除非它在进行动画，否则对于正常的用户交互，大多数人对于100毫秒内的更新是感觉不到有什么不同的。

    也就是说，只有在频繁进行超过100ms的纯CPU任务更新时，时间切片才实际有用。
    有趣的地方在于，这样的场景更经常地发生在React中，因为：

    1. React的虚拟DOM操作（reconciliation ）天生就比较慢，因为它使用了大量的Fiber架构；
    2. React使用JSX来渲染函数相对较于用模板来渲染更加难以优化，模板更易于静态分析。
    3. React Hooks将大部分组件树级优化（即防止不必要的子组件的重新渲染）留给了开发人员，开发人员在大多数情况下需要显式地使用useMemo。而且，不管什么时候React接收到了children属性，它几乎总要重新渲染，因为每次的子组件都是一棵新的vdom树。这意味着，一个使用Hook的React应用在默认配置下会过度渲染。更糟糕的是，像useMomo这类优化不能轻易地自动应用，因为：不幸的是，大多数开发人员都很懒，不会积极地优化他们的应用。所以大多数使用Hook的React应用会做很多不必要的CPU工作。
      1. 它需要正确的deps数组；
      2. 盲目地任意使用它可能会阻塞本该进行的更新，类似与PureComponent。

    相比之下，Vue就上面的问题做一下比较：

    1. 本质上更简单，因此虚拟DOM操作更快（没有时间切片-> 没有fiber-> 更少的开销）；
    2. 通过分析模板进行了大量的AOT优化，减少了虚拟DOM操作的基本开销。Benchmark显示，对于一个典型的DOM代码块来说，动态与静态内容的比例大约是1:4，Vue3的原生执行速度甚至比Svelte更快，在CPU上花费的时间不到React的1/10。
    3. 智能组件树级优化通过响应式跟踪，将插槽编译成函数（避免子元素重复渲染）和自动缓存内联句柄（避免内联函数重复渲染）。除非必要，否则子组件永远不需要重新渲染。这一切不需要开发人员进行任何手动优化。这意味着对于同一个更新，React应用可能造成多个组件重新渲染，但在Vue中大部分情况下只会导致一个组件重新渲染。

    默认情况下， Vue3应用比React应用花费更少的CPU工作时间， 并且CPU工作时间超过100ms的机会大幅度减少了，除非在一些极端的情况下，DOM可能成为更主要的瓶颈。
    现在，时间切片或并发模式带来了另一个问题：因为框架现在安排和协调了所有更新，它在优先级、失效、重新实例化等方面产生了大量额外的复杂性。所有这些逻辑处理都不可能被tree-shaken，这将导致运行时基线的大小膨胀。即使包含了Suspense和所有的tree-shaken，Vue 3的运行时仍然只有当前React + React DOM的1/4大小。
    注意，这并不是说并发模式是一个不好的主意。它提供一个有趣的新方法解决某一类问题(尤其是相关协调异步状态转换),但时间切片（作为并发的一个子特性）特别解决了React中比其他框架更突出的问题，同时也带来了成本。对于Vue 3来说，这种权衡似乎是不值得的。