1. 受控组件与非受控组件的本质区别1.1 先说一个生活化的例子很多人第一次接触“受控组件”和“非受控组件”这两个概念时容易被一堆React术语绕晕。我带你换个角度理解。想象你在填一张纸质报名表。如果这张表是“受控”的那么你每填一个字旁边都有一个工作人员立刻把内容同步到电脑系统里最终表格上显示什么、提交什么数据完全由系统说了算。而“非受控”的表单就好比你把纸拿回家自己填工作人员只在最后收表时才知道你写了什么——中间过程没人管也管不着。用React的说法受控组件的值由state“托管”每次输入都被React记录并回显非受控组件则把值“托管”给DOM自己React只在需要时通过ref去“问”DOM要数据。说白了这两者就是“React是否介入输入过程”的区别。受控组件是React全面接管非受控组件是React放手不管。1.2 这两个概念解决什么问题表单是前端开发绕不开的高频场景。用户在输入框里打字、勾选选项、上传文件这些交互产生的数据最终要么提交到后端要么在前端做实时联调。问题在于怎么拿到这些数据早期的做法是提交时统一读DOM后来有了React的数据驱动思想大家发现可以把输入框的值直接绑到状态上实现“所见即所得”。受控组件和非受控组件正是对这一问题的两套解决方案。如果你刚入门React或者正在用React脚手架搭后台管理系统理解这两个概念能帮你少走很多弯路遇到表单校验、联动、实时搜索这类需求你知道该选哪种遇到性能瓶颈、第三方组件数据流不清晰你也能快速定位问题。哪怕只是面试这个话题也是高频考点经常被拿来检验你对React数据流的理解深度。1.3 一句话记住核心区别受控组件值由React state控制数据流闭环是“state → 输入框 → onChange → setState → 回显”。非受控组件值由DOM自己管理React只在需要时通过ref读取。记住这句话后面的细节就都好懂了。2. 受控组件的原理与实操细节2.1 受控组件的完整数据流受控组件的核心是“单向数据流 显式反馈”。它的工作链路是这样的组件初始化时state给输入框一个初始值。用户输入时浏览器触发onChange事件。React把事件对象传给你写的事件处理函数你从e.target.value取值。调用setState更新state。React重新渲染输入框的value属性被新的state覆盖界面同步更新。看起来多了一步“绕回”但正是这一步让数据变得可预测。import { useState } from react; function ControlledInput() { const [value, setValue] useState(); const handleChange (e) { // 在这里可以做校验、格式化、联动等操作 setValue(e.target.value); }; return ( input typetext value{value} onChange{handleChange} placeholder请输入内容 / ); }这段代码里有个容易被新手忽略的细节onChange和value必须成对出现。如果你只给value绑state却忘了写onChange输入框会变成“只读”状态——因为React每次渲染都把值强制设为state而state从未更新用户输入永远无法生效。这既不是bug也不是React的限制而是受控组件“数据驱动UI”的设计逻辑。2.2 为什么非要绕一圈setState你可能想问既然用户已经在屏幕上输入了字符为什么不用e.target.value直接拿来用还要费力更新state再回显核心原因是“唯一数据源”。如果运行中有多个地方需要用到这个值——比如实时字数统计、搜索联想、联动另一个表单、提交前校验——它们都必须引用同一个数据源否则会出现“显示的内容和实际拿到的不一致”这种低级错误。受控组件的设计让所有逻辑都围绕state展开校验、格式化、联动都能放在handleChange里一并处理非常直观。const handleChange (e) { // 只允许输入数字 const numericValue e.target.value.replace(/[^\d]/g, ); setValue(numericValue); // 这里的value会以受控方式回显到输入框 };实操里我经常做类似格式化手机号只留数字、金额保留两位小数、标签转大写。这些需求在非受控组件里做会很别扭但受控组件天然适合。2.3 受控组件适合用在哪表单实时校验密码强度、邮箱格式、必填判断每次输入后立刻反映在UI上。跨组件联动比如选择省市区后自动筛选项搜索框输入影响下方表格。数据的即时处理输入时格式化手机号、金额或者统计剩余字数。提交前保障保证表单状态始终在React掌控下提交时拿到的就是最新值不会因为DOM没更新而丢数据。受控组件的优势是“可控”但代价是性能每次输入都会触发一次render。对中后台表单问题不大但如果输入极其频繁且组件树庞大就要考虑优化。2.4 受控组件最常踩的坑坑1只写value忘了onChange这个问题我刚才提过是出现频率最高的。症状是输入框无法输入任何内容或者输入后被立刻“清零”。排查方法很简单看value和onChange是否成对出现。坑2setState了但界面没反应很多人把setValue(e.target.value)写在onChange里结果发现输入框“卡顿”输得很慢。常见原因是组件写法不当导致渲染开销大比如onChange里做了重计算或者整个输入组件被包在一个过大的父组件里。解决方案把重计算用useMemo包起来确保onChange处理逻辑尽量轻量。坑3value和defaultValue混淆有的同学把value写成defaultValue发现输入框确实能显示初始值但之后用户输入就不受控了。一旦用了defaultValue这个输入框其实就已经变成非受控组件。要明确受控用value非受控用defaultValue两者不要混用。3. 非受控组件的原理与适用场景3.1 非受控组件到底“非控”在哪非受控组件的核心思路是React不跟踪输入框的实时内容值由原生DOM节点自己维护。当你需要取值时通过ref直接访问DOM节点拿到node.value即可。import { useRef } from react; function UncontrolledInput() { const inputRef useRef(null); const handleSubmit () { // 提交时才从DOM节点取值 alert(你输入的是${inputRef.current.value}); }; return ( div input typetext defaultValue默认内容 ref{inputRef} / button onClick{handleSubmit}提交/button /div ); }在非受控组件里React只负责初始渲染一旦渲染完成后续输入就跟React没关系了。用户输入的内容由DOM自己存着react的render函数不会介入每一帧的更新。3.2 非受控组件的较合适场景简单表单只有一两个输入框页面也不需要实时反馈提交时取值即可。与第三方库集成一些老旧的第三方库或jQuery插件会直接操作DOM用ref直接拿值反而更顺滑。文件上传input typefile /在React里是只读属性无法用受控组件管控其值必须用ref读文件。性能敏感场景输入极频繁每次onChange都setState会导致大量渲染拖垮体验时非受控反而更轻量。function FileUpload() { const fileRef useRef(null); const handleUpload () { const file fileRef.current.files[0]; console.log(file.name, file.size); // 后续上传逻辑 }; return ( div input typefile ref{fileRef} / button onClick{handleUpload}上传/button /div ); }文件框是React里不能做受控组件的典型例子因为浏览器不允许通过JS给文件框赋值这是安全层面的限制。3.3 非受控组件的优劣势维度优点缺点代码量更少不需要写onChange和setState没有这些代码逻辑松散性能不触发额外渲染更轻量高交互表单中很难做实时处理数据一致性React不介入数据源头是DOM一旦有多个地方需要同一份数据容易对不上可测试性写UI测试时更依赖DOM操作不便测输入逻辑断言价值有限可维护性简单场景一眼就懂复杂场景里出问题很难追溯从表格能直观看到非受控组件胜在简单和性能不适合复杂逻辑场景。3.4 非受控组件容易忽略的问题问题1直接读ref时未判空比如某个输入框在条件渲染下才出现事件触发时ref可能还是null直接读current.value会报错。写代码时记得加一层兜底const val inputRef.current ? inputRef.current.value : ;问题2受控组件与非受控搞混一个组件里某个字段受控另一个字段用defaultValue接到一个刚初始化完的state上数据的来源就会很乱。这种混用容易出隐蔽bug看代码也难定位。问题3需要拿到最新值时没同步非受控组件只有在提交或校验那一刻才能从DOM拿到值。如果使用方在UI操作过程中已经依赖这份数据却没有同步轻则显示延迟重则算错结果。4. 如何选型受控与非受控的权衡4.1 一张决策表帮你快速判断需求情况推荐方案原因输入时需要实时校验、字数统计受控每次输入都进React逻辑便于校验多个字段联动或跨组件共享数据受控统一数据源联动自然简单提交表单无中间状态非受控代码少、性能好集成老旧的第三方DOM库非受控避免数据流被第三方绕开引发不一致文件上传非受控浏览器限制只能通过ref取文件输入量极大组件树很重非受控或受控但优化避免高频触发渲染这张表不是绝对的但它覆盖了大部分实际需求。我个人的习惯是只要表单字段超过两个或存在联动、校验、提交后回显等需求一律用受控只有一次性提交的极简表单才敢放心用非受控。4.2 从产品需求反推实现方案具体选型时我的建议是先从产品角度问自己几个问题第一用户输入后页面上是否需要立即发生变化比如有一个搜索框输入时列表要实时过滤——这必须用受控。因为输入内容需要立即进入React的渲染流程去影响其他部分。第二这份数据是否会被多处引用比如“名字”输入框的值不仅要提交还要在页面顶部的欢迎语中显示甚至在另一个模块里被用来生成默认头像。数据被多处引用就必须由React统一持有。第三是否有严格的格式要求比如金额输入、手机号输入、只允许数字这些需要每次输入都做处理——受控组件可以拦在onChange里直接格式化。非受控组件做不到。第四是否要和其他组件的状态联动比如编辑表单时用户改某个字段另一个字段的值就要跟着变或者某个按钮的可点状态要变化。这类联动靠ref不好单向流用受控组件最清晰。4.3 受控与非受控可以共存很多团队对“受控”和“非受控”理解成两个非此即彼的阵营其实不是。一个表单里完全可以一部分字段受控另一部分用非受控根据实际字段特性来选。比如用户注册页“用户名”用受控实时校验格式“上传头像”用ref的非受控文件框“验证码”用受控提交时统一从ref和state里收集数据。混用时要特别留意提交时收集数据很多人只从state里取忘了一起读ref导致文件框数据丢失。建议把收集逻辑统一封装清晰区分数据来源。5. 从受控到非受控的改造实战5.1 一个改造前后的对比案例为了说明实际项目里的差异我用一个“实时字数统计”的需求来演示。起初我用非受控组件写了一个评论框输入后字数统计不更新想统计就得在提交时读DOM体验很差。非受控版本大概长这样const CommentBoxUncontrolled () { const textareaRef useRef(null); const [submittedCount, setSubmittedCount] useState(0); const handleSubmit () { const value textareaRef.current.value; setSubmittedCount(value.length); }; return ( div textarea ref{textareaRef} defaultValue / button onClick{handleSubmit}提交并显示字数/button p提交时统计到的字数{submittedCount}/p /div ); };页面看起来没有实时反馈用户输入50个字统计要等点提交才出来——这不合理。改成受控组件后输入第一个字符的瞬间字数统计就更新了const CommentBoxControlled () { const [value, setValue] useState(); const [count, setCount] useState(0); // write more concisely const handleChange (e) { const newValue e.target.value; setValue(newValue); setCount(newValue.length); }; return ( div textarea value{value} onChange{handleChange} placeholder写点什么... / p当前字数{count}/p /div ); };这个改动引发了一次全组讨论受控组件每次按键都render是否值得我们把页面切到性能面板实测发现对于普通textarea完全无感知相反实时反馈带来的体验提升是显而易见的。最后组里达成共识类似场景优先受控。5.2 改造过程中容易踩的坑坑1defaultValue改成value后输入框光标跳到末尾React在受控模式下如果setValue(old newChar)光标会跳到末尾但有时候用户是在光标中间插入文字这会导致体验问题。经验解法尽量用e.target.value或使用insertText等编辑API处理尽量避免在受控模式下用手动拼接字符串的方式更新state。坑2受控组件里处理中文输入法的候选词输入法选词时onChange会在候选词确认的瞬间触发。如果你在onChange里做状态逻辑中途打断选词可能导致包装的UI异常。实际操作中需要精确处理组合输入状态的场景可以考虑监听compositionstart和compositionend事件在组合输入期间先不更新state等确认后再同步。不过大多数常规表单不用这么复杂知道有这回事就行。坑3setState更新后被React异步批处理覆盖在同一事件里对同一个字段多次setStateReact会做批处理后一次覆盖前一次的变更。如果要基于上一次的值做增减要用函数式更新方式setCount(prev prev 1);这个写法在大量输入场景很重要很多人在这里翻过车。6. 进阶问题与面试高频追问6.1 React 19和未来趋势对这两个概念的影响React 19没有取消受控和非受控的概念而是继续优化性能。React团队长期在推动编译时的自动优化让开发者不用手动处理“该用ref还是state”。不过任何优化都没有改变核心原则只要React重新渲染受控组件就会用state覆盖输入框的值非受控组件则保持DOM原始状态。所以理解底层数据流比记忆某个版本的API更重要这点不变。6.2 面试时怎么回答这一问题面试官问“受控组件与非受控组件分别指什么”通常不只想听定义更想看你对数据流的理解。一个高分的回答框架可以是一句话定义受控组件由React state控制value非受控组件由DOM自己维护valueReact通过ref读取。举一个具体例子搜索框实时过滤是典型受控场景文件上传是典型非受控场景。指出优缺点受控可控性强、适合联动校验但性能开销稍大非受控代码简单、性能轻但数据不可追踪。谈谈你的选型策略没有绝对的好与坏根据场景做选型复杂表单选受控极简表单用非受控。这个框架既有深度又有实操经验面试官通常会更认可。6.3 面试官常问的几个变体问React的value和defaultValue有什么区别答value受控值始终来自statedefaultValue非受控只决定首次渲染的初始值之后由DOM接管。问为什么文件上传必须用非受控组件答浏览器的安全机制不允许JS给input typefile赋值所以React无法通过value来控制它只能通过ref读取用户选择的文件信息。问如果我从受控组件里清空state输入框会变空吗答会。setValue()后React重新渲染时value属性变成空字符串输入框立即清空。这就是受控的可预测性。问能举一个“受控不太好”的例子吗答一个极高频的实时编辑器每次输入都走完整React渲染如果组件树又比较大且未做优化性能可能出现明显下降。这种场景可以用非受控配合去优化的方式。6.4 给新手的实操建议如果你刚学React我的建议是先把受控组件练熟再学非受控。原因是受控组件能帮你培养“数据驱动UI”的思维习惯——想改界面就改数据想拿数据就取state。这是React里最核心的心智模型。等你想明白为什么需要这一套再去了解非受控组件反而一下就通了。练手时可以做一个小项目做一个带实时字数统计的评论区用户名、邮箱、留言各一个输入框其中邮箱要实时格式校验留言要字数上限提示。全程用受控组件实现做完你会发现对这两个概念的理解会上一个台阶。之后再用ref改造其中一个字段为非受控对比两种写法的差异。用同样的需求跑两遍你就能切身感受“什么时候值归React管什么时候归DOM管”。7. 个人踩坑后的总结最近在框架迁移时改造一个老模块原代码里同一个字段一会儿用value一会儿用defaultValue数据源混在一起调了两天才捋顺。教训很简单一个字段只能有一个数据管理者。受控让React管非受控让DOM管不能两个都管更不能两个都不管。另外我强烈建议团队在代码注释里写明组件属于哪种类型。一个输入组件如果用了受控新接手的人看到value和onChange就能判断如果用了非受控ref和defaultValue也是明显标记。但最怕的是混用的代码——一眼看不出来里面还藏着好几个隐藏的data流。我自己在项目里默认规则是表单类操作默认用受控组件除非有明显性能问题或第三方库集成需要才换成非受控。这个规则让大多数需求都能稳得住也让新同事上手时风格统一。你可以在自己的项目里试试这个规则大概率也会觉得省心。最后再分享一个小技巧在受控组件的onChange里不要写太长的逻辑尽量抽取成函数模块保持setState显式可见。别在事件处理函数里塞一堆嵌套判断不然半年后你回来看这段代码会头大。受控组件和非受控组件的差异说到底是一场“数据由谁说了算”的取舍。想清楚了这一点后面所有细节都会变得顺理成章。