React驯服表单的“野马”与“乖宝宝”本文以"野马"与"乖宝宝"比喻深入解析React受控与非受控组件。详述两种模式的

React驯服表单的“野马”与“乖宝宝”

引言：表单的"两副面孔"，你更爱哪一张？

各位前端老铁们，有没有在React里被表单搞得头大的经历？明明只是想简单地获取个输入框的值，结果发现它一会儿像脱缰的野马，爱咋咋地；一会儿又像个乖宝宝，你让它干啥它就干啥。这两种截然不同的"性格"，就是我们今天要聊的React表单的"受控"与"非受控"模式。别急，今天咱们就用最接地气、最幽默风趣的方式，把这对"欢喜冤家"彻底驯服！

想象一下，你是个经验丰富的驯兽师，而React里的表单元素（比如<input>、<textarea>、<select>）就是你面前那些形态各异的"小动物"。有些小动物天生放荡不羁爱自由，你给它个初始值，它就自己玩去了，后续的变化你得靠"偷窥"才能知道；而另一些小动物则乖巧听话，你得时刻牵着它的绳子，它的一举一动都在你的掌控之中。是不是有点意思？

那么，究竟什么是受控组件？什么又是非受控组件？它们各自有什么脾气秉性？又该在什么时候选择谁呢？别眨眼，好戏这就开场！

非受控组件：放荡不羁爱自由的"野马"

原理：组件内部说了算

咱们先来说说这"野马"——非受控组件。顾名思义，非受控组件就是指那些数据由DOM自身管理的表单元素。React不会去"控制"它们的值，你给它一个初始值（通过defaultValue属性），它就自己玩去了，后续用户在输入框里敲啥，那都是它自己的事儿，React不直接插手。

这就像你给孩子买了个玩具，告诉他"这是你的了，随便玩吧！"然后孩子就抱着玩具玩得不亦乐乎，你虽然知道他有这个玩具，但具体怎么玩、玩成啥样，你得凑过去看才知道。非受控组件就是这么个"放养"模式。

`defaultValue`：给"野马"一个初始方向

虽然非受控组件不被React直接控制，但我们还是可以给它一个初始值。这个初始值就是通过defaultValue属性来设置的。一旦设置了defaultValue，组件渲染时就会显示这个值，但之后用户对输入框的任何修改，都不会影响到React组件的状态，而是直接反映在DOM上。

来看个例子，下面的代码就是典型的非受控组件：

function App() {
  console.log("组件渲染");
  
  function onChange(event) {
    console.log(event.target.value) // 只是"偷听"一下
  }
  
  return (
    <input type="text" defaultValue={"hello"} onChange={onChange}/>
  )
}

在这个例子中，<input>元素通过defaultValue="hello"设置了初始值。用户可以在输入框中随意输入，onChange事件会打印出最新的值，但这个值并没有被React组件的状态所"捕获"和"管理"。

`useRef`：驯兽师的"套马索"

既然非受控组件的数据由DOM自身管理，那我们怎么才能获取到它的最新值呢？总不能真去"偷窥"DOM吧？这时候，React提供了一个"套马索"——useRef Hook。useRef可以让我们直接访问DOM元素，从而获取或修改非受控组件的值。

想象一下，useRef就像你手里的一根绳子，一端系在你的手上，另一端系在"野马"的脖子上。虽然你没有时刻拉着它，但当你需要知道它在哪儿、在干啥的时候，一拉绳子，它就过来了。

下面是useRef示例，它展示了如何通过useRef在组件加载后2秒获取输入框的值：

import { useEffect, useRef } from "react"
function App() {
   const inputRef = useRef(null)
   useEffect(() => {
     setTimeout(() => {
       console.log(inputRef.current.value);
     }, 2000)
   }, [])

   return (
     <input type="text" defaultValue={"hello"} ref={inputRef} />
   )}

在这个例子中，inputRef被关联到<input>元素上。当组件挂载后，我们就可以通过inputRef.current访问到真实的DOM节点，进而获取到它的value属性。这种方式通常用于需要与第三方DOM库集成，或者在某些特定场景下需要直接操作DOM的情况。

非受控组件的优缺点

优点：

简单粗暴： 对于简单的表单，不需要编写额外的状态管理代码，省事儿。
性能友好： 减少不必要的重渲染，性能开销相对较小。

缺点：

数据不同步： React组件的状态与DOM中的值不同步，如果需要实时获取或校验输入，会比较麻烦。
难以控制： 无法直接通过React的状态来控制表单的显示值，例如，你不能通过修改state来清空输入框。
校验困难： 实时输入校验、格式化等功能实现起来比较复杂，需要手动操作DOM。

总的来说，非受控组件就像一个"甩手掌柜"，把数据管理权交给了DOM。它适合那些你只关心最终提交结果，而不需要在输入过程中进行复杂交互或校验的场景。比如，一个简单的搜索框，你可能只关心用户最终点击搜索按钮时输入了什么，而不需要在用户输入过程中实时显示搜索建议。

受控组件：乖巧听话的"乖宝宝"

原理：React说了算

讲完了"野马"，咱们再来看看这"乖宝宝"——受控组件。与非受控组件截然相反，受控组件是指那些数据由React组件的状态（state）管理的表单元素。这意味着表单元素的值会受React状态的控制，每次用户输入，都会触发onChange事件，然后我们通过setState来更新组件的状态，再将这个状态值通过value属性"喂"给表单元素。

这就像你是个严格的家长，孩子玩什么玩具、怎么玩，你都得时刻盯着。孩子每动一下，你都要记录下来，然后根据你的记录来决定他下一步能怎么玩。受控组件就是这么个"精细化管理"模式。

`useState`与`value`：React的"遥控器"

在受控组件中，useState Hook 和 value 属性是核心。useState用来声明一个状态变量，存储表单元素的值；而value属性则将这个状态变量的值绑定到表单元素上。当用户输入时，onChange事件会触发，我们在这个事件处理函数中调用setState来更新状态，从而驱动UI的更新。

来看看下面的例子，它完美诠释了受控组件的工作方式：

import { useState } from "react"

function App2() {
    const [value, setValue] = useState("hello")
    
    function onChange(e) {
        console.log("受控组件输入值:", e.target.value)
        setValue(e.target.value.toUpperCase()) // 强制转大写，霸道总裁既视感
    }

    return (
        <input type="text" value={value} onChange={onChange}/>
    )
}

在这个例子中：

const [value, setValue] = useState(\'hello\')：我们声明了一个名为value的状态变量，并将其初始值设为\'hello\'。
<input type="text" value={value} onChange={onChange}/>：
- value={value}：将input的值绑定到value状态变量上。这意味着input的显示值完全由value状态决定。
- onChange={onChange}：当用户在input中输入时，onChange事件触发，调用onChange函数。
setValue(e.target.value.toUpperCase())：在onChange函数中，我们获取到用户输入的值（e.target.value），然后将其转换为大写，并通过setValue更新value状态。由于value状态更新了，React会重新渲染组件，input的显示值也随之更新为大写。

看到了吗？每次用户输入，值都会先经过React的状态管理，然后再"反馈"给DOM。这就是受控组件的"闭环"数据流。

受控组件的优缺点

优点：

数据同步： React组件的状态与DOM中的值始终保持同步，方便进行数据管理和操作。
易于控制： 可以轻松地通过修改state来控制表单的显示值，例如清空输入框、设置默认值等。
实时校验与格式化： 可以在onChange事件中实时进行输入校验、格式化、过滤等操作，提升用户体验。
集成方便： 方便与Redux、MobX等状态管理库集成，实现更复杂的数据流管理。

缺点：

代码量增加： 对于每个需要受控的表单元素，都需要编写useState和onChange处理函数，代码量相对增加。
性能开销： 每次用户输入都会触发组件重新渲染，对于高频输入的场景，可能会有轻微的性能开销（但通常可以忽略不计，React已经做了很多优化）。

总的来说，受控组件就像一个"尽职尽责的管家"，把表单的数据管理得井井有条。它适合那些需要实时反馈、复杂校验、或者需要与其他状态管理逻辑紧密结合的场景。几乎所有需要用户输入的表单，都推荐使用受控组件。

受控组件 vs 非受控组件：到底选谁？

听完"野马"和"乖宝宝"的故事，你可能要问了：这俩货到底哪个好？啥时候用哪个？别急，咱们来个大PK，看看它们各自的适用场景。

特性	受控组件（Controlled Component）	非受控组件（Uncontrolled Component）
数据来源	React组件的状态（state）	DOM自身
数据流	单向数据流：用户输入 -> `onChange` -> `setState` -> `value` -> UI更新	双向数据流：用户输入直接更新DOM，React通过`ref`获取
控制程度	完全受控，React完全掌控表单值	不受控，表单值由DOM自身管理
初始值	`value`属性	`defaultValue`属性
获取值	通过state变量直接获取	通过`ref`获取DOM元素，再获取其`value`属性
实时校验	方便，可在`onChange`中实时处理	困难，需要手动操作DOM或在提交时校验
代码量	相对较多，需要`useState`和`onChange`处理函数	相对较少，特别是简单表单
性能	每次输入都触发重新渲染（通常可忽略）	性能开销小，不频繁触发重新渲染
适用场景	绝大多数表单场景，需要实时反馈、复杂校验、与状态管理库集成	简单表单，只需获取最终提交值，或与非React的DOM操作库集成

何时选择"乖宝宝"（受控组件）？

一句话总结：几乎所有需要用户输入的表单，都应该优先考虑受控组件。

需要实时输入校验和格式化： 比如用户输入手机号时自动添加空格，或者输入密码时实时显示密码强度。
需要根据输入内容动态改变UI： 比如输入框有内容时显示清除按钮，或者根据输入内容过滤列表。
需要与其他状态管理库（如Redux）集成： 受控组件的数据流与React的状态管理模式高度契合。
需要表单重置、预填充等操作： 通过修改state可以轻松实现这些功能。
需要构建复杂表单： 多个输入框之间存在联动关系时，受控组件能更好地管理数据流。

举个例子，一个注册表单，你需要实时校验用户名是否可用，密码是否符合要求，邮箱格式是否正确……这时候，受控组件就是你的不二之选。它能让你轻松地在用户输入的同时进行各种"骚操作"。

何时选择"野马"（非受控组件）？

一句话总结：当你真的、真的、真的不需要React来管理表单的实时状态时。

简单的文件上传输入框： 文件输入框（<input type="file">）通常是非受控的，因为它的值是只读的，只能由用户选择文件来设置。
与第三方DOM库集成： 如果你正在使用一些直接操作DOM的第三方库（比如某些旧的jQuery插件），为了避免冲突，可能会选择非受控组件。
性能敏感的场景（极少数）： 理论上，非受控组件的性能开销更小，因为它不涉及React的状态更新和重新渲染。但在绝大多数情况下，这种性能差异可以忽略不计。除非你遇到了极端性能瓶颈，否则不建议为了这点性能牺牲可维护性。
只需要获取最终提交值： 比如一个简单的搜索框，你只关心用户点击搜索按钮时输入了什么，而不需要在输入过程中进行任何处理。

一个忠告： 除非你有非常明确的理由，否则请尽量使用受控组件。它能让你的代码更可预测、更易于维护，也能让你更好地利用React的强大生态。非受控组件更像是一个"逃生舱"，在特殊情况下使用，但日常航行还是得靠"主舰"。

常见问题解答（FAQ）

Q1: 我能在同一个表单中混用受控组件和非受控组件吗？

A: 技术上可以，但强烈不推荐。混用会让你的代码变得难以维护和理解。就像你不会在同一个团队里既用军事化管理又用放羊式管理一样，保持一致性是最好的选择。如果你真的需要混用，请确保你有充分的理由，并且在代码中明确注释说明。

Q2: 为什么我的非受控组件设置了`value`属性后，输入框变成只读了？

A: 这是React的一个保护机制。当你给一个输入框设置了value属性但没有提供onChange处理函数时，React会认为你想要一个只读的输入框。如果你想要非受控组件，请使用defaultValue而不是value。

Q3: 受控组件每次输入都会重新渲染，这不会影响性能吗？

A: 在绝大多数情况下，这种性能影响可以忽略不计。React已经做了大量优化，而且现代浏览器的性能也足够强大。除非你遇到了明显的性能瓶颈（比如一个页面有成百上千个输入框），否则不需要为此担心。记住，过早优化是万恶之源。

Q4: 什么时候应该使用`useRef`？

A: useRef主要用于以下场景：

需要直接访问DOM元素（如聚焦输入框、滚动到特定位置）
与第三方DOM库集成
存储不需要触发重新渲染的可变值
在非受控组件中获取表单值

Q5: 我听说React推荐使用受控组件，那非受控组件是不是过时了？

A: 非受控组件并没有过时，它们在特定场景下仍然有用武之地。React推荐受控组件是因为它们更符合React的设计理念，但这不意味着非受控组件就是"错误"的。选择哪种模式应该基于你的具体需求，而不是盲目跟风。

Q6: 如何在受控组件中处理复杂的表单校验？

A: 对于复杂的表单校验，你可以：

在onChange事件中进行实时校验
使用useState管理校验状态和错误信息
考虑使用成熟的表单库（如Formik、React Hook Form）
将校验逻辑抽取到自定义Hook中以提高复用性

Q7: 文件上传输入框应该用哪种模式？

A: 文件上传输入框（<input type="file">）通常是非受控的，因为出于安全考虑，JavaScript无法设置文件输入框的值。你只能读取用户选择的文件，而不能程序化地设置文件。这是浏览器的安全限制，不是React的问题。

最佳实践：优雅的"控制艺术"

经过这一番学习，相信你已经对React的受控组件和非受控组件有了深入的理解。作为一名优秀的前端开发者，掌握以下最佳实践将让你在表单处理的道路上如虎添翼：

1. 优先选择受控组件

除非有特殊需求，否则请优先选择受控组件。它们更符合React的设计理念，也更容易维护和测试。

2. 保持一致性

在同一个项目中，尽量保持表单处理方式的一致性。不要在这里用受控组件，那里用非受控组件，这会让代码变得混乱。

3. 合理使用`useRef`

useRef是个强大的工具，但不要滥用。只在真正需要直接操作DOM的时候才使用它。

4. 注意性能优化

对于大型表单，考虑使用React.memo、useMemo、useCallback等优化手段，但记住：先让代码工作，再让代码快速。

5. 善用表单库

对于复杂的表单场景，不要重复造轮子。Formik、React Hook Form等成熟的表单库可以大大提高你的开发效率。

6. 编写清晰的代码

无论选择哪种模式，都要确保代码清晰易懂。适当的注释和有意义的变量名比任何优化都重要。

总结：驯兽师的智慧

好了，各位驯兽师们，经过一番"驯服"之旅，相信你对React的受控组件和非受控组件已经有了更深入的理解。它们就像表单世界的"阴"与"阳"，各有各的特点，各有各的用武之地。

受控组件：是React推荐的、更"React式"的表单处理方式。它让React完全掌控表单数据，实现数据与UI的同步，方便进行实时校验、格式化和复杂的交互。它就像一个时刻在你掌控之中的"乖宝宝"，你指哪打哪，一切尽在掌握。
非受控组件：则更接近传统的HTML表单行为，数据由DOM自身管理。它在某些特定场景下（如文件上传、与第三方DOM库集成、或极度简单的表单）能提供更简洁的代码，但牺牲了React对数据的直接控制。它就像一匹放养的"野马"，虽然自由，但你需要额外的方法（useRef）才能"套住"它，获取它的信息。

作为一名优秀的前端开发者，掌握这两种模式并能根据实际需求灵活选择，是你的必备技能。记住，没有最好的，只有最适合的。愿你在React的表单世界里，既能驾驭"野马"，也能培养"乖宝宝"，成为真正的"表单驯兽大师"！

希望这篇博客能帮助你更好地理解React的受控组件与非受控组件。如果你有任何疑问或想分享你的"驯兽"经验，欢迎在评论区留言，我们一起交流学习！

React驯服表单的“野马”与“乖宝宝”