React框架核心原理解析
写 React 代码久了，会觉得自己像在搭积木。早上刚把一个弹窗拖进页面，下午产品就跑来说要再加个“暗黑模式”，于是你复制组件、改样式、再塞个状态，天一黑，页面亮了。可一旦项目变大，积木堆得越高，摇起来越晃。有时候改一个输入框，旁边不相关的列表也跟着闪一下；有时候明明数据没变，页面却重跑了一遍。那一刻你大概会想：React 到底在背后搞什么名堂？
我第一次被 React “背刺”，是在一个电商详情页。两个开发各自维护一块区域，我负责商品信息，另一位负责推荐列表。大家约定好用 props 传数据，看起来井水不犯河水。结果上线那天，服务器一压测，商品库存一变化，推荐列表像被打了鸡血一样疯狂重渲染。控制台里一排排的组件名闪得让人心慌。后来我们关掉一些不必要的状态提升，页面才安稳下来。那件事让我明白：React 不是“写一遍就完事”，它的核心原理其实一直在帮你做取舍，只是你没看清规则。
再往后做项目，遇到表单联动，一个页面几十个字段，校验、联动、异步提交，状态像打结的耳机线。试着用 useState 各自为政，结果输入一个邮编，城市和街道要联动，却总慢半拍。换成 useReducer 加 useContext 后，页面稳了一些，可还是偶尔卡顿。那段时间我开始去抠 React 的调度逻辑，去看它怎么把一次“用户操作”拆解成可以中断、可以优先级排队的工作。原来，框架不只是个库，它在试图理解“用户究竟想要什么”，并尽量用最小的代价给出来。
很多团队会把 React 当黑盒：写 JSX，绑事件，useEffect 里请求数据，跑起来就上线。可一旦线上出性能问题，定位起来像在雾里找路。其实 React 的核心原理并不玄乎，它围绕三个问题打转：界面如何描述、更新如何发生、渲染节奏如何控制。把这三个问题捋顺，很多“莫名其妙”的卡顿和重渲，就能找到源头。
我们太容易把“写得快”当成“架构好”。可 React 真正厉害的地方，是它用一套规则把不确定性压到最低。它不强迫你写某种目录结构，却用组件和状态边界逼你思考“什么该一起变，什么不该一起变”。这种克制，往往比炫技更重要。
要理解 React，第一绕不开的是“UI = f(state)”。这句话看似简单，却把前端开发从“操作 DOM”拉回到“描述结果”。过去我们习惯用 jQuery 选中一个节点，改它的类名、属性、文本，像在指挥一群工人搬砖。React 则让你写一张图纸：给定当前状态，它自己负责把界面变成那个样子。你不用管怎么删节点、加节点，只要告诉它“如果是这样，就长那样”。
JSX 就是这张图纸的语法糖。写 <Button disabled={isSubmitting}>提交</Button> 时，你其实在构造一种轻量级的对象描述。React 拿到它，不会立刻去动 DOM，而是先在心里记下“期望长这样”。等真正要干活时，它会比较新旧两张图纸，找出差异，再动手。这种“比较”的过程，叫调和（Reconciliation）。调和的目标很明确：尽量少动 DOM，因为 DOM 操作慢，且容易打断用户输入。
调和的关键在于“节点身份”。React 用 key 和组件类型来判断一个节点是“移动了”还是“换了人”。比如一个列表，如果没有 key，删掉第一项时，React 可能以为每一项都变了，只好全部重绘；加上 key，它就能认出谁还在原位，只做最小的更新。这在大量数据展示时特别明显。见过一个后台管理系统，表格没加 key，排序一次全屏闪，加了 key 之后，动画顺得像丝滑。所以，key 不是为了 React，是为了让调和算法少干活。
组件的分与合，本质上是在为调和提供边界。一个大组件里塞太多逻辑，任何一点风吹草动都会让它重新解释整块图纸。拆成小组件，相当于把图纸切成小块，变化的局部只需要重绘局部。可拆分不是无脑切，得顺着“状态变化的方向”切。哪些 state 经常一起变，就放在同一个组件里；哪些 state 各过各的，就分出去。这样，调和的时候，React 就能跳过不相关的子树。
有了描述，就要有更新。React 的更新触发机制，像一个层层传递的信使。事件处理函数里 setState，只是把“要更新”的请求发出去，真正执行更新，React 会统一安排。这个安排的过程，叫调度。
早年的 React 是同步的。一旦 setState，组件就开始重渲染，卡就卡，用户也只能等。后来 React 引入了 Fiber 架构，把一次更新拆成很多小单元。每个 Fiber 节点对应一个组件实例，记录它的 props、state、与子节点和兄弟节点的关系。更新时，React 可以走一段、看一眼：如果有更紧急的事（比如用户输入），就暂停渲染，先响应输入；等空闲了，再继续。这种“可中断的渲染”，让页面在复杂场景下依然能保持响应。
优先级是调度的核心。React 会给不同类型的更新打上标签：用户点击、输入往往是高优先级；数据预加载、批量更新可以低优先级。Suspense 和 Concurrent Mode 的出现，让 React 能在等待异步数据时，先展示占位，而不是干等。这种体验上的“顺滑”，背后是一套复杂的优先级计算和任务切片机制。
但调度再聪明，也救不了混乱的状态管理。见过一个项目，几十个 useState 散落在组件里，props 像蜘蛛网一样层层透传，最后谁也不敢动。状态提升（lifting state up）曾经是最佳实践，可一提就到顶层，所有组件跟着重渲染。Context 出现后，数据可以跨层级传递，但 Context 的值一变，所有订阅的组件都会重渲染，哪怕它们只用到了其中一小部分。于是社区流行“拆 Context”，把高频更新的值和低频分开放，或者用状态管理库做更细粒度的订阅。
React 自己不限制你怎么存状态，但它用规则提醒你：状态越靠近使用它的地方，越容易控制。useReducer 适合复杂联动，useCallback 和 useMemo 适合稳住引用，避免不必要的子组件重渲染。可这些优化不是免费的午餐，用多了，代码会变难读。关键在于“先让逻辑正确，再让渲染合理”。
渲染节奏的控制，是 React 真正拉开差距的地方。一次更新，通常会经历两个阶段：Render 阶段和 Commit 阶段。Render 阶段可以中断，React 会根据优先级和过期时间，决定要不要继续往下算虚拟 DOM 的差异。这个阶段产生的结果，是一组“要做的 DOM 操作”。Commit 阶段则必须一口气完成：React 会依次执行生命周期、DOM 变更、ref 赋值。因为这时候用户已经能看见变化，所以不能停顿。
useEffect 的设计，就和这个两阶段模型紧密相关。它在 Commit 阶段之后执行，属于“副作用”。把数据请求、订阅、手动 DOM 操作放在这里，是为了避免阻塞界面展示。可这也带来陷阱：useEffect 里的依赖如果漏写，副作用可能跑在旧数据上；不写，又可能跑得太频繁。很多人把 useEffect 当“万能钩子”，结果页面里塞满交错运行的副作用，调试起来像破案。
React 18 的自动批处理，让多个 setState 在同一事件循环中被合并，一次只触发一次渲染。这让代码更“宽容”：你可以在一个函数里改好几个状态，不用担心渲染次数失控。但这也意味着，不能指望 setState 后立刻拿到最新 DOM。React 把决定权收回到自己手里，开发者要适应“声明式”的思维方式。
性能优化在 React 里更像一场“平衡游戏”。React.memo 能拦住无关的组件重渲染，可如果 props 总是新引用，它就形同虚设。useMemo 和 useCallback 能稳住引用，可滥用会让内存和 GC 压力上升。真正有效的优化，往往来自结构调整：把高频更新的状态下沉，把计算放到事件处理函数里，而不是渲染函数里。
回到文章开头那堆“积木”。React 的核心原理，其实就是一套关于“边界、优先级和最小代价”的规则。组件是边界，调和是比对，调度是排队，渲染是两阶段提交。它不强迫你写完美的代码，但会惩罚混乱的结构。当你开始思考“这个 state 应该属于谁”“这个更新有多急”“这个组件要不要拆”，你就已经在用 React 的方式思考了。
写 React 项目久了，会发现最难的往往不是技术，而是取舍。哪些状态放一起，哪些效果延迟执行，哪些渲染可以跳过。这些决定，决定了页面是“越用越慢”还是“越用越稳”。框架给的是工具，真正搭建秩序的，是写代码的人。
所以，下次再遇到莫名其妙的重渲染，别急着加 memo。先看看组件边界是否合理，状态是否离使用它的地方太近，更新是否被不必要地提升到太高的地方。React 的原理并不复杂，它只是希望你：描述清楚，安排妥当，少动 DOM，把时间还给用户。
当页面在深夜依然顺滑，当弹窗在暗黑模式下安静亮起，你会觉得，之前那些和状态、调度、调和较劲的日子，都值得。毕竟，React 不是魔法，它只是把复杂的前端世界，拆解成一块块可以理解的积木。而我们能做的，是学会怎么搭。