⚡ 30 秒速记

• 核心判断：状态更新是否立刻可见取决于调度边界和批处理，不应简单记成“同步”或“异步”
• 原理主线：围绕 「一、前言」、「二、什么是 Immutable Data」、「三、为什么要在React.js中使用Im」 建立输入、状态变化与输出之间的因果关系
• 文章范围：介绍了在React开发中使用Immutable数据结构的原理、优势及其对组件性能优化的作用，涵盖了setState、shouldComponentUpdate、深拷贝与Immutable.js等相关内容，帮助开发者理解如何高效管理和优化前端
• 边界与代价：React 18 自动批处理范围扩大，读取旧值、连续更新和强制同步提交需要分别讨论
• 工程落地：依赖前值时使用函数式更新；只有确有 DOM 读取时才考虑同步提交，并评估阻塞代价

Immutable Data 的价值是更新后返回新对象，同时保留旧数据不变，并用结构共享控制复制成本。 某个深层节点变化时，只重建该节点及其父链，未变化的分支继续复用，因此比每次 deep clone 更适合频繁状态更新。对 React 来说，引用变化可配合浅比较更快判断是否需要重渲染，也方便撤销、重做和状态回溯。代价是要学习新的 Map、List 等 API，还要处理与原生对象混用及资源体积问题。

这篇文章不要按 API 清单来背。先用上面的 Mind Map 建立全局结构，再通过交互 DEMO 观察正常路径和边界路径如何改变状态；阅读正文时重点核对每一步的输入、负责执行的参与者、产生的中间状态以及最终可观察结果。遇到版本敏感结论，要把“历史实现”“当前行为”和“工程兼容策略”分开说明；遇到性能或架构取舍，则用实际指标、失败现象和验证手段支撑判断。

版本校准： 原理文章中的代码代表特定实现与写作时间。应用到当前项目时，应先确认浏览器、框架或工具的主版本，再区分稳定的规范语义、可变化的内部实现和项目自身约束。

一、前言

从问题说起：熟悉 React 组件生命周期的话都知道：调用 setState 方法总是会触发 render 方法从而进行 vdom re-render 相关逻辑，哪怕实际上你没有更改到 Component.state

this.state = {count: 0}
this.setState({count: 0});// 组件 state 并未被改变，但仍会触发 render 方法 

• 为了避免这种性能上的浪费，React 提供了一个 shouldComponentUpdate 来控制触发 vdom re-render 逻辑的条件。于是 PureRenderMixin 作为一种优化技巧被使用。它仅仅是浅比较对象，深层次的数据结构根本不管用

js中的Immutable Data

在javascript中我们可以通过deep clone来模拟Immutable Data，就是每次对数据进行操作，新对数据进行deep clone出一个新数据