表单是React应用里最容易踩坑的环节之一，尤其是受控组件与非受控组件的边界问题。不少人在开发中遇到过这样的场景：给输入框设置了defaultValue，同时又绑定了onChange，结果发现输入行为时而正常时而异常，控制台还会冒出一条警告，提示不能同时为input提供value和defaultValue。这篇文章就来把这个问题彻底讲清楚，看看defaultValue与onChange到底能不能一起用，以及混合场景下如何正确同步数据。
受控与非受控组件的本质区别
要理解混合使用的问题，得先明白两种模式的底层逻辑。受控组件的核心是表单元素的值完全由React的state驱动，你给<input>设置value属性，再通过onChange把用户的输入写回state，形成一个闭环。数据流向是单向的：state决定显示内容，用户输入触发onChange，onChange更新state，state再反过来刷新输入框。这种方式让表单数据始终处于React的掌控之中，方便做校验、格式化和条件联动。
非受控组件则是另一条路线，表单的值由DOM节点自己维护，React只是通过defaultValue设置一个初始值，之后用户改了什么，React并不实时感知，需要取值时通过ref去读取DOM的真实值。这种方式写起来更省事，更接近传统HTML的行为，代价是你失去了对输入过程的实时控制能力。
两者的关键差异可以用一张表来概括：
| 特性 | 受控组件 | 非受控组件 |
|---|---|---|
| 值来源 | React state | DOM自身 |
| 初始值 | value属性 | defaultValue属性 |
| 取值方式 | 直接读state | 通过ref读取DOM |
| 实时校验 | 支持，每次输入都能拦截 | 不支持，只能提交时校验 |
defaultValue与onChange混用会发生什么
先说结论：defaultValue和onChange是可以同时存在的，React并不会因此报错，但两者的组合方式决定了组件的行为。真正的雷区在value和defaultValue同时出现，React会直接警告你这样做会让value属性失效，因为defaultValue只在组件首次挂载时生效，一旦后续又设置了value，React就不知道该听谁的了。
先看一个常见的错误写法：
function BadInput() {
const [val, setVal] = useState('hello');
return (
<input
value={val}
defaultValue="world"
onChange={e => setVal(e.target.value)}
/>
);
}这段代码会触发警告，因为value和defaultValue被同时提供了。实际运行时value优先生效，defaultValue被忽略，虽然功能上看似没问题，但这种写法埋下了隐患，后续维护者很难判断组件的真实意图。
另一个更隐蔽的坑是value值在运行过程中变成undefined或null。看这个例子：
function TrickyInput({ data }) {
const [val, setVal] = useState('');
useEffect(() => {
if (data) setVal(data.name);
}, [data]);
return <input value={val} onChange={e => setVal(e.target.value)} />;
}如果data.name在某些时刻是undefined，输入框会从受控模式悄悄退化成非受控模式，控制台会警告一个组件从受控切换到非受控是不允许的。解决办法很简单，给value加个兜底：value={val ?? ''}，确保任何情况下都是字符串。
混合场景的正确同步方案
实际业务中最常见的需求是：表单初始值来自后端接口，接口返回前希望输入框保持非受控状态或显示默认值，接口返回后切换成受控模式做实时同步。针对这种场景，推荐用一个明确的标记来区分两个阶段，而不是依赖defaultValue和value的隐式优先级。
方案一：用state初始化完成切换。
function HybridInput({ initialName, onNameChange }) {
// 只在首次拿到初始值时使用非受控行为
const [isReady, setIsReady] = useState(false);
const [name, setName] = useState('');
useEffect(() => {
if (initialName !== undefined && !isReady) {
setName(initialName);
setIsReady(true);
}
}, [initialName, isReady]);
return (
<input
value={name}
onChange={e => {
const v = e.target.value;
setName(v);
onNameChange?.(v);
}}
/>
);
}这个方案的本质是始终用value保持受控，只是把初始值的填充推迟到数据到位之后。看起来没有用到defaultValue，但它规避了混合模式的所有坑，是最稳妥的做法。
方案二：确实需要defaultValue时，用key强制重置。有些场景下表单结构复杂，全部受控会导致大量state和handler，此时可以用defaultValue配合key，当外部数据变化时通过更换key让组件整体重新挂载，defaultValue自然生效。
function SimpleForm({ user }) {
return (
<form key={user.id}>
<input defaultValue={user.name} name="name" />
<input defaultValue={user.email} name="email" />
<button type="submit">提交</button>
</form>
);
}切换用户时key变了，整个表单重新渲染，defaultValue以新数据重新初始化，既省去了逐个字段维护state的成本，又保证数据同步正确。需要注意的是，重新挂载会丢失表单内所有的未保存输入和焦点状态，适合整条记录切换的场景，不适合频繁局部刷新。
常见问题与排查思路
遇到输入框无法输入的问题，第一步检查是不是设置了value却没有绑定onChange。受控组件缺少onChange时，输入框会变成只读，React会警告你提供一个onChange或者改用readOnly属性。第二步检查value是否可能为undefined，尤其是值来自接口或复杂对象属性时，加兜底值几乎应该成为肌肉记忆。
关于onChange在非受控组件中的使用也要澄清一下：onChange完全可以配合defaultValue使用，它不会让组件变成受控组件，只是让你在用户输入时收到通知。这种组合适合只关心输入结果而不需要实时干预的场景，比如搜索框的防抖上报，输入过程交给DOM管理，onChange里做节流处理即可。
总结一下选择原则：需要实时校验、格式化、联动控制就用受控组件；表单字段多、只需提交时取值就用非受控加ref；初始值异步到达时优先考虑推迟state初始化或用key重置，而不是强行让value和defaultValue共存。理解了React对表单值的接管机制，这些警告就不再是玄学，而是帮你提前发现设计缺陷的提示。
React受控组件defaultValueonChange修改时间：2026-09-13 13:34:37