其实不光是他，我见过不少刚接触React的开发者都卡在这一步：受控组件和非受控组件，到底该怎么选？选对了，表单逻辑清爽得像喝冰水；选错了，不是代码冗余到没法维护，就是用户输入和页面显示“打架”。今天咱们就掰开揉碎了说——从数据流向到实战场景，带你搞懂这两个“表单冤家”的真面目，以后写表单再也不用纠结。
核心区别：数据流向决定谁在“主导”
要搞懂这俩组件的区别，得先抓住核心：谁在控制数据。就像你管理钱包，是自己每天记账（受控），还是随手丢抽屉等用钱时翻（非受控）——不同的管理方式，带来的体验天差地别。
受控组件：“state管家”实时盯着每一分钱
受控组件就像你手机里的记账APP，每笔支出都即时记录，余额实时更新。在React里，它的数据完全由组件内部的state（状态）控制：用户输入内容时，会触发onChange事件，你在事件里更新state，然后state再把新值“同步”给输入框显示。整个流程是“state→UI→用户输入→更新state→UI再更新”，形成一个闭环。
举个最常见的例子：一个简单的用户名输入框。用受控组件写是这样的：
function UsernameInput() {
const [name, setName] = useState('');
return (
type="text"
value={name}
onChange={(e) => setName(e.target.value)}
/>
);
}
这里输入框的value直接绑着state里的name，用户每敲一个字，onChange就调用setName更新name，输入框马上显示新内容。你可以在setName里加各种逻辑，比如限制输入长度（超过10个字不让输）、格式化（首字母自动大写），甚至实时验证（输入时判断是不是邮箱格式）——因为所有操作都通过state“中转”，你能完全掌控数据的每一步变化。
我去年做过一个企业后台的“员工信息录入系统”，里面有个“薪资计算”模块：基本工资输入后，要实时算出社保、公积金和税后收入，还要根据薪资范围显示不同的税率提示。当时团队一开始想用非受控组件，觉得“反正最后提交时拿一次值就行”，结果写验证逻辑时彻底懵了——用户改了基本工资，社保金额没跟着变；税率提示要等用户点“计算”按钮才更新，测试时被吐槽“像在用十年前的网站”。后来全改成受控组件，把薪资、社保、税后收入都存在state里，基本工资一变化，其他字段通过state联动更新，税率提示实时弹出来，用户反馈直接从“差评”变成“丝滑”。这就是受控组件“实时响应”的优势——数据在你手里，想怎么折腾都行。
非受控组件：“DOM自治”的野生派
非受控组件就不一样了，它更像你爸妈那辈的“抽屉记账法”：钱塞抽屉里，花了多少、剩多少全凭记忆，要用的时候才打开抽屉数数。在React里，非受控组件的数据不由state管，而是交给DOM自己“保管”——输入框的值存放在DOM节点里，你要拿值的时候，得用ref（引用）手动“访问”DOM节点才能取到。
还是刚才的用户名输入框，用非受控组件写是这样的：
function UsernameInput() {
const inputRef = useRef(null);
const handleSubmit = () => {
console.log('用户名：', inputRef.current.value);
};
return (
);
}
这里输入框没有value属性绑定state，用户输入的内容直接存在DOM里。只有点击“提交”按钮时，才通过inputRef.current.value拿到值。这种方式好处是“简单直接”，不用写onChange和state，代码量少一半；但坏处也明显——你没法实时知道用户输入了什么，想限制长度、格式化内容？要么用原生JS监听input事件（绕回受控的逻辑），要么等提交时再处理（用户可能已经输入了一堆无效内容）。
我朋友小李上个月做个人博客的“搜索框”，就踩过非受控组件的坑。他觉得“搜索框嘛，简单，输完点按钮就行”，用了非受控组件，结果用户反馈“按回车搜不了”——因为非受控组件默认不处理键盘事件，得自己加onKeyPress判断是否按了回车。后来他改成受控组件，把搜索词绑到state，再监听onKeyPress，按下回车就触发搜索，问题才解决。这就是非受控组件的“野生”特点：DOM自己说了算，你想干预？得多费点劲。
一张表看清：受控vs非受控的核心差异
为了让你更直观对比，我整理了一张表，把两者的关键特性列出来——你写代码时对着表查，选错的概率能降80%：
| 特性 | 受控组件 | 非受控组件 |
|---|---|---|
| 数据管理者 | React state（组件内部状态） | DOM节点自身 |
| 值更新方式 | 通过setState主动更新 | 用户输入直接修改DOM，无需主动更新 |
| 取值时机 | 随时可通过state获取（实时） | 需通过ref手动获取（通常在提交时） |
| 适用操作 | 实时验证、格式化、多字段联动 | 简单取值、原生表单行为、第三方库集成 |
| 代码复杂度 | 需写onChange和state逻辑（略复杂） | 无需state，代码简洁（简单场景） |
React官方文档其实早就说透了两者的定位：“受控组件更适合需要对用户输入进行即时响应的场景”（引自React官方文档）。但文档没说的是——实际开发中，很多人会“用受控组件写简单表单嫌麻烦，用非受控组件写复杂表单又搞不定”，这才是真正的痛点。
场景选择：从“够用”到“好用”的实战心法
知道了区别，接下来的问题是：什么场景该用哪个？我见过两种极端：有人不管三七二十一全用受控组件，连个搜索框都写三行state代码；也有人觉得非受控组件“省事”，拿ref一把梭，结果写复杂表单时被验证逻辑逼疯。其实选对组件的核心，就一个原则：让组件的“控制力度”匹配场景的“复杂度”。
简单场景：非受控组件的“舒适区”
如果你的表单满足这两个条件：
，那非受控组件就是“性价比之王”。典型例子：登录框、搜索框、简单的留言板。
比如登录表单——用户输账号密码，点“登录”按钮后才需要拿值。用非受控组件写，代码能省一半：
function LoginForm() {
const usernameRef = useRef(null);
const passwordRef = useRef(null);
const handleLogin = () => {
const data = {
username: usernameRef.current.value,
password: passwordRef.current.value
};
// 发送登录请求...
};
return (
{ e.preventDefault(); handleLogin(); }}>
);
}
这里不需要实时验证（输账号时不用提示“账号格式不对”），也不需要联动（改账号不影响密码），非受控组件足够用了。我前年给一个餐饮小程序写“快速点餐”功能，里面有个“备注”输入框——用户填不填都行，填了就提交时发给后厨。当时用非受控组件+ref，代码干净得像新洗的盘子，上线后也没出任何问题。
还有两种特殊场景，非受控组件几乎是“唯一解”：
复杂场景：受控组件的“主场”
如果你的表单涉及实时反馈、多字段联动、复杂验证，那受控组件就是“刚需”。比如注册表单（实时验证手机号格式）、地址填写（省市区联动）、电商的“购物车结算”（改数量实时算总价）。
我去年做的“在线考试系统”里，有个“多选题”组件：选了A选项，B选项可能变成不可选；选满3个选项后，其他选项自动禁用；提交前还要检查“至少选2个”。这种场景用非受控组件根本玩不转——你得监听每个选项的变化，手动判断联动关系，代码写出来像“意大利面”。后来全改成受控组件，把选中的选项存在一个state数组里，选项变化时更新数组，再根据数组长度和内容控制其他选项的“disabled”属性，逻辑瞬间清晰：
function MultiChoice() {
const [selected, setSelected] = useState([]);
const options = ['A', 'B', 'C', 'D'];
const handleChange = (option) => {
if (selected.includes(option)) {
setSelected(selected.filter(item => item !== option));
} else {
// 最多选3个
if (selected.length < 3) {
setSelected([...selected, option]);
}
}
};
return (
{options.map(option => (
type="checkbox"
checked={selected.includes(option)}
onChange={() => handleChange(option)}
disabled={selected.length >= 3 && !selected.includes(option)}
/>
{option}
))}
{/ 实时提示选中数量 /}
已选：{selected.length}个（至少选2个）
);
}
这里“选中状态”“禁用逻辑”“数量提示”全靠state联动，用户选选项时，界面实时响应，体验直接拉满。如果用非受控组件，你得写一堆ref监听，还容易出现“选了第四个选项但界面没禁用”的bug——我同事之前就踩过这坑，最后老老实实改成了受控组件。
混合场景：别当“极端分子”
有时候你会遇到“半复杂”场景：大部分简单，但有一两个字段需要实时反馈。这时候别非黑即白，局部用受控，其他用非受控反而更灵活。比如“用户资料页”：姓名、生日这些字段不需要实时验证，但“密码”字段需要显示“强度提示”（弱/中/强）。这时候可以只把密码做成受控组件，其他字段用非受控组件：
function ProfileForm() {
// 只有密码需要实时验证，所以只给密码定义state
const [password, setPassword] = useState('');
const nameRef = useRef(null);
const birthdayRef = useRef(null);
// 密码强度计算逻辑
const getStrength = () => {
if (password.length < 6) return '弱';
if (password.match(/[a-z]|[A-Z]|[0-9]/g).length < 2) return '中';
return '强';
};
return (
{/ 非受控：姓名 /}
{/ 非受控：生日 /}
{/ 受控：密码（带实时强度提示） /}
type="password"
value={password}
onChange={(e) => setPassword(e.target.value)}
placeholder="密码"
/>
强度：{getStrength()}
);
}
这种“混合模式”既能减少不必要的state代码，又能满足局部实时反馈的需求。不过要注意：千万别在同一个表单里让受控和非受控组件“管理同一个数据”——比如用state控制input的value，同时又用ref去改DOM的值，结果就是state和DOM“各说各话”，数据彻底乱套。
避坑指南：3个“反常识”的实操技巧
最后分享3个我踩过坑才 出来的“实战技巧”，帮你少走弯路：
：我见过新人觉得“用受控组件显得专业”，结果写个简单的“意见反馈”表单，加了5个state，onChange写得比业务逻辑还长。记住：工具是为场景服务的，简单场景用非受控组件不丢人。
：如果需要非受控组件的简洁，又想要一点控制能力，可以用defaultValue（默认值）。比如编辑用户资料时，从接口拿初始值填到输入框，用defaultValue比state更简单：
但注意：defaultValue只在组件首次渲染时生效，之后改defaultValue不会更新输入框——这和受控组件的value完全不同。
：写完表单后，打开React DevTools（F12→Components），看看输入框的“value”是不是跟着state变（受控），还是“value”在DOM里（非受控）。之前团队有个bug，表单提交时总有字段是空的，查了半天才发现——某个输入框写成了非受控组件，却以为是受控的，state更新了但DOM没同步。用DevTools一看，输入框的value根本没绑state，瞬间破案。
你最近在写什么表单？是简单的登录框，还是带联动验证的复杂表单？不妨试试今天说的“场景匹配法”，选对组件后，可能会发现代码突然变清爽了。如果试了有效果，或者遇到了新问题，欢迎在评论区告诉我——前端开发就是这样，有时候选对工具，比多写100行代码更有用。
说实话，使用受控组件会不会影响性能，这个问题我被问过好几次了。其实答案很简单：一般情况下真不会，但你得注意别搞“多余的状态更新”。就拿最简单的场景来说，比如一个单独的搜索框，用户输入时触发onChange更新state，再同步到输入框显示——这过程看起来“步骤多”，但现代React自己优化重渲染的能力已经很强了，用户根本感觉不到延迟。我之前给一个博客写搜索功能，用受控组件绑定输入值，实时显示搜索 每天几千人用，也没听谁说过“卡”。倒是见过有人为了“省性能”用非受控组件，结果后面加搜索历史记录功能时，还得手动存ref的值到localStorage，代码反而多写了十几行，有点本末倒置了。
不过复杂场景就得另说了。比如我去年帮朋友的电商网站改结算页面，里面有收货地址、优惠券、发票信息好几个模块，选了A省B市，运费自动变；勾了“开发票”，公司名称输入框才显示——这种多字段联动的情况，你要是不用受控组件，非用非受控组件硬扛，那才叫“给自己找罪受”。当时朋友的前开发就是用非受控组件写的，代码里全是ref.current.value，验证逻辑绕来绕去，改个运费规则得翻半天代码。后来我全换成受控组件，把所有值存在一个state对象里，哪个字段变了就更新对应的属性，联动逻辑直接写在setState后面，清爽得不行。所以说，选受控还是非受控，别光盯着“性能”两个字，先想想你的表单逻辑复不复杂——逻辑捋顺了，代码好维护，比省那点“理论性能”重要多了。
受控组件和非受控组件的根本区别是什么？
核心区别在于数据由谁控制。受控组件的数据完全由React的state管理，用户输入会实时触发onChange事件更新state，再同步到UI，形成“状态驱动UI”的闭环；非受控组件的数据由DOM自身管理，需通过ref手动获取值，更接近原生表单行为。简单说，受控组件是“主动管理”，非受控组件是“被动获取”。
怎么快速判断该用受控组件还是非受控组件？
记住一个原则：看是否需要实时反馈或复杂控制。如果表单需要实时验证（如输入时提示格式错误）、多字段联动（如选A选项后B选项禁用）、格式化（如手机号自动加空格），选受控组件；如果只是简单取值（如登录框、搜索框）、无需实时处理，或集成第三方库，选非受控组件。
使用受控组件会影响性能吗？
一般不会，但需注意避免不必要的状态更新。受控组件每次输入都会触发state更新和重渲染，在极简单场景（如单个输入框）可能略冗余，但现代React的重渲染优化已足够高效；复杂场景（如多字段联动、实时验证）必须用受控组件，否则逻辑会更混乱。非受控组件虽减少状态更新，但手动管理ref反而可能增加维护成本，需权衡场景复杂度。
同一个表单里，受控组件和非受控组件能混合使用吗？
可以，但千万别让它们管理同一数据。比如用state控制A输入框的value，同时用ref获取B输入框的值，没问题；但如果既用state又用ref操作同一个输入框，会导致state和DOM数据“不同步”，出现输入框显示和实际值对不上的bug。混合使用的正确姿势是：简单字段用非受控，需要实时控制的字段用受控，各司其职。
defaultValue和value有什么区别？能混用吗？
不能混用，作用完全不同。value是受控组件的属性，必须配合state使用，值会随state实时更新；defaultValue是非受控组件的初始值，只在组件首次渲染时生效，之后修改defaultValue不会更新UI。比如非受控组件用defaultValue设置初始值后，用户输入会直接改DOM值，和defaultValue无关；而受控组件用value绑state，用户输入必须通过setState才能更新显示。
