React框架核心原理解析
写 React 之前，我总觉得自己在和“页面”打交道。
有个做电商的朋友跟我吐槽：用户往购物车加个商品，整个商品列表闪一下，价格要等半秒才变。他说自己写的代码像在修水管——哪里漏了贴哪里，修完又漏。后来他用 React 重写了一版，页面“啪”地一下就顺滑了。他得意地说，不是代码变少了，而是脑子终于不用替浏览器打工了。
这种“不用替浏览器打工”的感觉，就是 React 想给开发者的第一份礼物。
写页面像搭积木，而不是像拼电路
我以前写页面，喜欢一上来就抓 DOM，像在拼电路：找到节点、改属性、加监听，哪一步错了一步都不亮。
有次做一个表单，十几个输入框联动，我用原生写，onchange 里套 onchange，改着改着发现改乱了——一个框清空，另一个框却填进了旧值。排查了半天，才发现某个节点被重复创建了，事件还挂在老节点上。
换成 React 之后，页面更像搭积木：你只管描述“现在应该长什么样”，React 负责去把它摆到屏幕上。数据变了，积木重新拼一次；没变的积木，原地不动。这种“描述式”的写法，一开始不习惯，但写顺手了，会发现错误变少了，因为不再需要手动指挥浏览器每一步该走哪。
把界面拆成一块一块的可组合单元
React 的核心思路其实很朴素：把大界面拆成小块，小块还能继续拆。
我见过一个后台系统，首页密密麻麻几十个模块，原先是一个几千行的文件，改样式要滚动半天。后来拆成 Header、Sidebar、CardList、EmptyState 这样的小组件，每个组件只关心自己的输入和输出。
有个细节很关键：组件不是按“页面位置”拆的，而是按“功能边界”拆。比如一个评论框，它包含头像、昵称、输入框、提交按钮，这些东西经常一起出现，就放在一起。换到另一个页面，只要数据和行为一致，直接复用。
拆出来的好处是：改一处，不容易踩到另一处。你甚至可以假装某个接口没写好，先用一个假组件占位，开发照样跑得起来。等真的接口好了，替换进去就行。拆得干净，团队协作起来也更像拼乐高，而不是传纸条。
用“状态”驱动界面，而不是用“操作”驱动
很多前端问题的根子，不在写得慢，而在想得乱：到底哪一步操作导致了哪一步变化？
我早些年写页面，习惯在事件里直接改 DOM。按钮一点，把文字颜色改了，再把数字加一，再发个请求……写着写着，发现同样的逻辑在三个地方各写了一遍。
React 换个角度：界面是状态的投影。状态像舞台上的灯光，界面是灯光照出来的影子。灯光一变，影子自动变，不用你手动去描。
比如一个开关按钮，按下去不是去“把字变蓝”，而是去“把 isOn 变成 true”。界面里只写：isOn 为 true 就显示蓝色，否则灰色。这样哪怕以后要加动画、加权限、加埋点，你只需要改状态的变化路径，界面本身不动。
状态集中之后，bug 也更容易定位——你不需要猜是哪个操作改错了，只需要看状态为什么变成了现在这样。
不直接动 DOM，而是用“虚拟”的方式安排更新
浏览器其实很笨：动一下 DOM，它就要重新算样式、排版、绘制。你要是频繁改，页面就会卡。
React 的办法是“别总去动它”。它在内存里维护一棵“虚拟 DOM”，先把新的界面结构算好，再和旧的比一遍，找出真正不一样的地方，最后只去改那些地方。
我见过一个实时数据看板，每秒刷一次。以前用原生写，每次全量替换表格，滚动条会跳，用户体验很割裂。换成 React 之后，只有数值变了的那几行被更新，滚动条稳如老狗。
这种“比对—最小更新”的机制，并不只是性能优化，更是一种思维上的松绑：你不再需要小心翼翼地控制每一次修改，而是相信框架会替你安排好最省力的路径。
把变化收拢成一次“提交”，而不是零散的动作
还有一个容易忽略的点：React 把一系列变化打包成一次“提交”。
就像你去银行办事，不是每填一张表就跑一次柜台，而是填完一起交。React 也是：你改了多个状态，它不立刻去改界面，而是等一个合适的时机，统一处理。
这带来了两个好处：一是避免中间状态被界面看到，减少闪烁和抖动；二是让逻辑更可预测。你写 useEffect 的时候，可以清楚地知道“这些状态稳定之后，我要做什么”，而不是在每次小变化里反复试探。
我见过一个搜索框，用户打字太快，原先的实现每打一个字母就发请求，结果接口堵住了。换成 React 之后，配合防抖和状态合并，只在用户停下来的那一刻发请求，服务器轻松了，用户也不焦虑了。
写 React 写久了，会发现它其实在教你怎么组织复杂度。
页面越大，越容易乱；而 React 提供的组件、状态、更新机制，像是一套默认约定：把变化收拢，把边界划清，把手动操作减到最少。它不是让你写得更快，而是让你改得更稳。
那个做电商的朋友后来跟我说，他现在写代码像在指挥一支乐队：每个组件是一件乐器，状态是乐谱，React 是指挥家。乐谱一变，大家一起响；不需要他一个一个去敲锣打鼓。
如果你也受够了“哪里漏了贴哪里”的开发日常，不妨试着用 React 的方式想一想：界面能不能被描述？变化能不能被收拢？边界能不能被拆清？
有时候，换个写法，不是为了炫技，而是为了让脑子有余力去思考更重要的事——比如用户真正需要什么，而不是浏览器今天又闹什么脾气。