一、为什么总在面试里被追问“受控和非受控”
前端技术迭代飞快，新的状态管理库、新的响应式语法层出不穷，可无论框架如何翻新，面试现场依旧绕不开那个经典提问——“请说说受控组件和非受控组件的区别”。原因在于：
前端技术迭代飞快，新的状态管理库、新的响应式语法层出不穷，可无论框架如何翻新，面试现场依旧绕不开那个经典提问——“请说说受控组件和非受控组件的区别”。原因在于：
-
这是数据流向的“元问题”，直接体现开发者对“状态到底放在哪”的理解深度；
-
项目里 80% 的“页面改完没反应”“数据回显不对”“性能突然爆炸”都可以追溯到两类组件的混用；
-
选型错误往往要在产品上线后才会暴露，返工成本极高，团队需要在编码第一行就达成共识。
本文抛开具体框架语法，把“受控”与“非受控”抽象成两种数据哲学：一条缰绳牵到底，还是放马归山。
二、概念回溯：状态究竟在谁手里
受控组件的“控”指“数据源被 React/Vue/Angular 等框架状态牢牢控制”，用户输入先触发事件，再更新框架状态，最后由框架把新值灌回组件，完成闭环。此时屏幕上的展示与内存中的变量是 1:1 镜像，任何时点的快照都可预测。
非受控组件则把状态托管给 DOM 自身，框架只在需要时通过引用去“读取”或“设置”值。用户敲入字符，浏览器负责更新输入框，内存中的变量可以“暂时不同步”，直到业务逻辑显式索要数据。
一句话记忆：
受控组件的“控”指“数据源被 React/Vue/Angular 等框架状态牢牢控制”，用户输入先触发事件，再更新框架状态，最后由框架把新值灌回组件，完成闭环。此时屏幕上的展示与内存中的变量是 1:1 镜像，任何时点的快照都可预测。
非受控组件则把状态托管给 DOM 自身，框架只在需要时通过引用去“读取”或“设置”值。用户敲入字符，浏览器负责更新输入框，内存中的变量可以“暂时不同步”，直到业务逻辑显式索要数据。
一句话记忆：
-
受控——“数据在框架里，DOM 是投影”；
-
非受控——“数据在 DOM 里，框架是访客”。
两种模式没有天然的优劣，就像“手动挡”与“自动挡”，关键看路况与驾驶习惯。
三、数据流向对比：一圈闭环 versus 一段直线
受控流向呈“环形”：键盘输入 → 事件处理器 → setState → Virtual DOM Diff → 实际 DOM 更新。
非受控流向呈“直线”：键盘输入 → DOM 更新 → 业务需要时再读取。
环形的好处是“可追踪”，任何中间节点都能被打印、回放、拦截；代价是“每一步都要写代码”。直线的好处是“少写很多样板”，代价是“中间过程对框架不可见”，调试时只能打断点或打印 DOM。
理解流向对排障至关重要。遇到“值没更新”的投诉，如果项目采用全程受控，开发者只要顺着环形节点逐段 console；如果混用了非受控，就要把直线部分也纳入排查半径，否则永远少一块拼图。
受控流向呈“环形”：键盘输入 → 事件处理器 → setState → Virtual DOM Diff → 实际 DOM 更新。
非受控流向呈“直线”：键盘输入 → DOM 更新 → 业务需要时再读取。
环形的好处是“可追踪”，任何中间节点都能被打印、回放、拦截；代价是“每一步都要写代码”。直线的好处是“少写很多样板”，代价是“中间过程对框架不可见”，调试时只能打断点或打印 DOM。
理解流向对排障至关重要。遇到“值没更新”的投诉，如果项目采用全程受控，开发者只要顺着环形节点逐段 console；如果混用了非受控，就要把直线部分也纳入排查半径，否则永远少一块拼图。
四、更新时机：同步与异步的感官差异
受控组件的更新通常是“同步触发、异步渲染”。即 setState 会立刻修改内存，但框架为了批量优化，可能把 DOM 更新推迟到下一帧。
非受控组件的更新则是“同步触发、同步渲染”。因为浏览器负责把值填进输入框，用户敲下键盘的瞬间就能看到结果，感官上“更跟手”。
在需要“实时校验”“输入过程高亮”的场景，非受控的同步感会让体验更顺滑；而在需要“联合校验”“多字段勾稽”的场景，受控的异步批处理能减少一半以上的重复计算。把“感官差异”混同为“性能差异”是初学者最容易陷入的误区。
受控组件的更新通常是“同步触发、异步渲染”。即 setState 会立刻修改内存，但框架为了批量优化，可能把 DOM 更新推迟到下一帧。
非受控组件的更新则是“同步触发、同步渲染”。因为浏览器负责把值填进输入框，用户敲下键盘的瞬间就能看到结果，感官上“更跟手”。
在需要“实时校验”“输入过程高亮”的场景，非受控的同步感会让体验更顺滑；而在需要“联合校验”“多字段勾稽”的场景，受控的异步批处理能减少一半以上的重复计算。把“感官差异”混同为“性能差异”是初学者最容易陷入的误区。
五、性能视角：谁更慢，谁更快
-
受控的“慢”来自额外渲染
每一次按键都可能导致父组件、兄弟组件、子组件集体刷新。若未加 memo 或 shouldUpdate，长列表输入框会出现肉眼卡顿。 -
非受控的“慢”来自读取时快照
在提交瞬间需要一次性读取大量 DOM 值，如果同时触发校验、转换、序列化，主线程会被长时间霸占，用户感觉“点击保存后卡了一下”。 -
量化方式
用性能工具分别统计“输入阶段”与“提交阶段”的脚本执行时长，而非只看总体 FPS。多数场景下，受控输入阶段脚本时长更高，非受控提交阶段脚本时长更高。只要数值落在 16 ms 安全线以内，差异对用户不可见；一旦超标，就要考虑“分页加载”“异步提交”等通用优化，而不是纠结“受控与否”。
六、测试差异：如何写“可靠断言”
受控组件的测试聚焦“状态”：
受控组件的测试聚焦“状态”：
-
模拟用户输入 → 断言内存变量 → 断言 DOM 值
测试用例不依赖真实 DOM，可跑在 Node 环境，速度快。
非受控组件的测试聚焦“DOM”： -
模拟用户输入 → 断言 DOM 值 → 再断言内存变量
必须挂载真实 DOM，常用无头浏览器，启动慢但更接近用户真实场景。
混用模式下，测试策略也要分层： -
对受控部分用“状态断言”保证逻辑正确；
-
对非受控部分用“DOM 快照”保证渲染正确；
-
对边界交互（受控改非受控、非受控回调触发受控）用端到端用例覆盖，避免“各自测试都通过，集成后却掉链子”。
七、典型反模式：混用、假受控、僵尸引用
-
混用
同一表单里，用户名输入框用受控，密码输入框用非受控，导致“重置”按钮只能清空用户名，密码纹丝不动。用户惊呼“这是 BUG 吗”，开发却解释“这是特性”，信任瞬间崩塌。 -
假受控
表面上 setState，实际上状态更新后没有回传 value，DOM 值与内存值分道扬镳。表现是“第一次输入正常，第二次输入突然归零”，调试时很难发现。 -
僵尸引用
非受控组件被卸载后，业务逻辑仍保留其引用，再次读取时拿到的是过期值，造成“提交的是上一次的旧数据”。
规避原则：
-
一个表单只选一种模式，中途不切换；
-
若必须切换，先把旧值同步到统一状态，再销毁旧组件；
-
引用生命周期与组件生命周期保持一致，卸载即清空。
八、渐进式迁移：从“非受控”走向“受控”不会翻车
-
先锁定“读写接口”
把散落在各处的 input.value 读取封装成 getFormData()，把各处赋值封装成 setFormData()，先统一入口，再替换内部实现。 -
再引入“影子状态”
在内存里维护一份 mirrorState，初始值从 DOM 读取，后续输入全部走受控更新，但暂不提交后端，给测试回归留缓冲期。 -
双轨校验
提交前同时用“影子状态”与“DOM 快照”做交叉校验，若不一致就报警，收集足够多现场数据后，再彻底去掉 DOM 读取。 -
清理引用
全局搜索所有 formerRef.current，配合单元测试覆盖率，确认归零后，再删除相关依赖。
整个过程像“给飞行中的飞机换发动机”，每步都可回滚，业务无感知。
九、设计哲学：数据主权与业务复杂度的权衡
受控代表“框架主权”，一切变更都要经过框架调度，适合：
受控代表“框架主权”，一切变更都要经过框架调度，适合：
-
需要时光旅行、撤销重做、协同编辑
-
需要多字段联合计算、实时依赖图谱
-
需要严格审计、版本比对、操作回放
非受控代表“浏览器主权”，让原生能力发挥最大性能，适合： -
一次性收集、一次性提交
-
字段之间无耦合，各管各的
-
需要嵌入第三方插件、富文本、地图等“黑盒”
把主权问题想明白，选型就水到渠成。最怕的是“先写个 Demo 用非受控，业务膨胀后逐步加状态”，最后变成“半吊子受控”，既失去性能优势，又得不到数据便利。
十、未来趋势：更细粒度的“半受控”
随着编译器与运行时的融合，越来越多的框架提出“按需受控”理念：
随着编译器与运行时的融合，越来越多的框架提出“按需受控”理念：
-
只有被框架监听的状态才走受控路径
-
未被监听的部分保持非受控性能
-
监听粒度可细化到“字段级别”而非“组件级别”
这种模式让开发者无需二选一，框架在编译期自动插入最优策略。对用户而言，依旧是写同样的模板语法，却能在“性能敏感”场景拿到非受控的丝滑，也能在“逻辑复杂”场景拿到受控的可预测。
值得注意的是，“半受控”对调试工具提出更高要求，开发者需要能一眼区分“哪一段是影子变量、哪一段是 DOM 快照”，否则问题定位难度会指数级上升。
