受控与非受控组件

引言：数据驱动的本质

在 React 的组件化架构中，表单处理始终是一个核心议题。理解受控组件与非受控组件的区别，不仅是掌握 React 基础语法的必经之路，更是深入理解"数据驱动视图"这一核心设计哲学的关键。

我们可以通过一个生动的场景来类比这两种模式：

受控组件（Controlled Component） 类似于高级餐厅的点餐服务。顾客（用户）的每一个需求，都需要经过服务员（React State）的确认与记录，最终由厨房（DOM）精准执行。在这个过程中，服务员掌握着唯一的、绝对的控制权。
非受控组件（Uncontrolled Component） 则类似于自助餐模式。顾客直接选取食物（直接操作 DOM），餐厅管理者（React）并不实时干预盘子里的内容，只有在结账（表单提交）的时刻，才进行一次性的核对。

这种差异的核心在于：表单数据的"单一数据源（Single Source of Truth）"究竟是归属于 React 组件的 State，还是浏览器原生的 DOM 节点？

受控组件：单一数据源

定义与核心机制

在受控组件模式下，useState 成为表单数据的唯一可信源。HTML 表单元素（如、、）通常维护自己的内部状态，但在 React 中，我们将这种可变状态保存在组件的 state 属性中，并且只能通过 setState() 来更新。

标准代码实现

Jsx

ini 复制代码

import React, { useState } from 'react';

function ControlledInput() {
  const [value, setValue] = useState('');

  const handleChange = (e) => {
    // 数据流向：View -> Event -> State -> View
    const input = e.target.value;
    // 在这里可以进行数据清洗或验证
    setValue(input.toUpperCase()); 
  };

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

深度解析

受控组件的价值在于其即时响应特性。由于每一次按键都会触发 React 的状态更新流程，开发者可以在 onChange 回调中介入数据流：

输入验证（Input Validation） ：即时反馈输入是否合法（如长度限制、正则匹配）。
数据转换（Data Transformation） ：如上例所示，强制将输入转换为大写，或格式化信用卡号。
条件禁用：根据当前输入值动态决定提交按钮是否可用。

在这种模式下，DOM 节点不再持有状态，它仅仅是 React State 的一个纯函数投影。

非受控组件：信任 DOM 的原生能力

定义与核心机制

非受控组件是指表单数据由 DOM 节点本身处理。在大多数情况下，这需要使用 useRef 来从 DOM 节点中获取表单数据。此时，React 变成了"观察者"而非"管理者"。

标准代码实现

注意：在非受控组件中，我们使用 defaultValue 属性来指定初始值，而不是 value。这是为了避免 React 覆盖 DOM 的原生行为。

Jsx

javascript 复制代码

import React, { useRef } from 'react';

function UncontrolledInput() {
  const inputRef = useRef(null);

  const handleSubmit = (e) => {
    e.preventDefault();
    // 只有在需要时（如提交）才读取 DOM 值
    console.log('Current Value:', inputRef.current.value);
  };

  return (
    <form onSubmit={handleSubmit}>
      {/* defaultValue 仅在初次渲染时生效 */}
      <input type="text" defaultValue="Initial" ref={inputRef} />
      <button type="submit">Submit</button>
    </form>
  );
}

核心优势与不可替代场景

虽然受控组件是 React 的推荐模式，但在以下场景中，非受控组件具有不可替代性：

文件上传（File Input） ：的值是由浏览器出于安全考虑严格控制的只读属性，React 无法通过 state 设置它，因此必须作为非受控组件处理。
集成第三方 DOM 库：当需要与 jQuery 插件、D3.js 或其他直接操作 DOM 的库集成时，非受控组件能避免 React 的虚拟 DOM 机制与第三方库产生冲突。

进阶实战：复杂组件的设计哲学

在实际的业务开发中，我们经常遇到一种混合模式：内部受控，外部非受控。以一个通用的"日历组件"为例，这种设计模式能显著降低组件使用者的心智负担。

场景描述

我们需要封装一个 Calendar 组件。对于父组件而言，它可能只需要关心"初始日期"和"最终选中的日期"；但对于 Calendar 组件内部，它需要处理月份切换、当前日期高亮等复杂的交互逻辑。

模式分析

Jsx

javascript 复制代码

import React, { useState } from 'react';

function Calendar(props) {
  // 1. 接受 props.defaultValue 作为初始状态
  // 2. 即使 props.onChange 未传递，组件内部也能正常工作
  const { defaultValue = new Date(), onChange = () => {} } = props;
  
  // 3. 内部维护 State，实现"自我管理"
  const [date, setDate] = useState(defaultValue);

  const handleDateClick = (newDate) => {
    // 更新内部状态，驱动 UI 重绘（如高亮选中项）
    setDate(newDate);
    // 抛出事件通知外部
    onChange(newDate);
  };

  // 省略月份切换与日期渲染逻辑...

  return (
    <div className="calendar-container">
       {/* 渲染逻辑基于内部 state.date */}
       <div className="current-month">
         {date.getFullYear()} 年 {date.getMonth() + 1} 月
       </div>
       {/* ... */}
    </div>
  );
}

设计价值

这个日历组件展示了高级组件设计的精髓：

对内受控：组件内部通过 useState 精确控制每一个 UI 细节（月份跳转、选中态样式），确保交互的流畅性。
对外非受控：父组件不需要维护 value 状态即可使用该组件（开箱即用）。父组件只通过 defaultValue 初始化，并通过回调获取结果。

这种"封装复杂性"的设计，使得组件既拥有受控组件的灵活性，又具备非受控组件的易用性。

深度对比与选型指南

多维度对比

数据流向
- 受控组件：Push 模式。State -> DOM。数据变更主动推送到视图。
- 非受控组件：Pull 模式。DOM -> Ref。仅在需要时从视图拉取数据。
渲染机制
- 受控组件：每次输入（Keystroke）都会触发组件的 Re-render。
- 非受控组件：输入过程不触发 React 组件的 Re-render（除非内部有其他 State 逻辑）。
代码复杂度
- 受控组件：较高，需要为每个输入编写 onChange 处理函数。
- 非受控组件：较低，代码结构更接近原生 HTML。

性能辩证

一种常见的误解是"受控组件性能差"。诚然，受控组件每次输入都触发渲染，但在 React 18 的并发模式（Concurrent Features）和自动批处理机制下，这种性能损耗对于绝大多数普通表单（少于 1000 个输入节点）是可以忽略不计的。

仅在极端高性能场景下（如高频数据录入表格、富文本编辑器核心），非受控组件才具有明显的性能优势。

决策树：如何选择？

在进行技术选型时，请遵循以下原则：

必须使用非受控组件：
- 文件上传 ([ ] )。
- 需要强依赖 DOM 行为的遗留代码迁移。
强烈建议使用受控组件：
- 需要即时表单验证（输入时报错）。
- 需要条件字段（根据输入 A 显示输入 B）。
- 需要强制输入格式（如手机号自动加空格）。
灵活选择：
- 简单的登录/注册表单，无复杂联动：两者皆可，非受控代码更少。
- 开发通用 UI 库：建议参考实战案例，采用"defaultValue + 内部 State"的混合模式，提供更好的开发者体验。