一、核心概念：什么是受控 / 非受控模式？
在 React 中，表单元素的数据管理方式是区分两种模式的核心标准，本质是「数据控制权」的归属问题：
1. 受控模式（Controlled Components）
- 定义：表单元素的数据由 React 组件的 state 完全控制，表单元素本身不存储数据，仅作为「数据展示与用户交互载体」。
- 核心逻辑：用户操作表单 → 触发事件（如 onChange）→ 更新组件 state → state 反向渲染到表单元素 → 完成数据同步。
- 典型特征：通过 value（输入类元素）或 checked（单选 / 复选框）绑定 state，通过事件处理器控制数据流转。
2. 非受控模式（Uncontrolled Components）
- 定义：表单元素的数据由 DOM 自身维护（类似原生 HTML），React 组件通过「 refs」 间接获取 DOM 中的数据，不主动管理数据状态。
- 核心逻辑：用户操作表单 → DOM 自动更新数据 → 组件通过 ref 从 DOM 中读取数据（通常在提交时）。
- 典型特征：使用 defaultValue（默认值）或 defaultChecked 初始化数据，无需绑定 onChange 实时同步，依赖 DOM API 获取最新值。
二、代码实现：两种模式的具体用法
1. 受控模式示例（表单输入框）
- 关键：value={inputValue} 让输入框的值完全由 state 控制，用户输入必须通过 handleChange 更新 state 才能生效，支持实时数据校验、格式化等需求。
2. 非受控模式示例（表单输入框）
- 关键：defaultValue 仅用于初始化，后续用户输入直接修改 DOM value，组件不跟踪实时变化，仅在需要时（如提交）通过 ref 读取。
三、深入解析：原理与适用场景
1. 受控模式：数据驱动的精准控制
- 工作原理：基于 React 的「单向数据流」，表单数据是组件 state 的一部分，组件是数据的「唯一数据源」，任何数据变化都需通过 setState 触发重新渲染，确保 UI 与数据始终一致。
- 适用场景：
- 需要实时数据校验（如密码强度提示、输入格式限制）；
- 需要数据联动（如一个输入框变化影响另一个输入框）；
- 表单复杂，需统一管理所有字段状态（如多步骤表单）；
- 需要即时反馈用户操作（如搜索框实时联想）。
- 优势：数据可控性强，易调试（可通过 state 跟踪数据变化），支持复杂业务逻辑；
- 劣势：代码量稍多，需为每个表单元素编写事件处理器，高频输入（如输入框实时输入）可能触发频繁渲染（可通过 debounce 优化）。
2. 非受控模式：贴近原生的简洁方案
- 工作原理：复用原生 DOM 的表单处理逻辑，数据存储在 DOM 节点中，React 仅作为「旁观者」，通过 ref访问 DOM API 操作数据，无需维护 state 与表单的同步。
- 适用场景：
- 简单表单（如登录框、单个输入框提交），无需实时处理数据；
- 集成第三方 UI 组件（部分第三方组件仅支持非受控模式）；
- 性能优化场景（如海量输入框，避免频繁 setState 渲染）；
- 快速开发原型，无需复杂数据控制逻辑。
- 优势：代码简洁，减少冗余逻辑，贴近原生开发体验，避免频繁渲染；
- 劣势：数据可控性弱，难以实现实时校验 / 联动，调试需操作 DOM，可能出现 UI 与数据不一致（如手动修改 DOM value 未同步到组件）。
四、关键对比：核心差异一览
| 对比维度 | 受控模式 | 非受控模式 |
|---|---|---|
| 数据存储位置 | React 组件 state | DOM 元素自身 |
| 数据更新方式 | 触发 onChange → 更新 state → 重新渲染 | 直接修改 DOM，组件不主动跟踪 |
| 初始化方式 | value={state}（动态绑定） | defaultValue（静态初始化） |
| 数据获取方式 | 直接读取 state | 通过 ref 读取 DOM 值 |
| 实时校验支持 | 支持（onChange 中处理） | 不支持（需手动监听 DOM 事件） |
| 代码复杂度 | 稍高（需编写事件处理器） | 较低（复用原生逻辑） |
| 适用场景 | 复杂表单、实时交互、数据联动 | 简单表单、原型开发、第三方组件集成 |
五、实践避坑指南
- 避免「混合模式」：不要同时设置 value 和 defaultValue，也不要在受控组件中直接修改 DOM 值，否则会导致数据不一致或警告。
- 受控组件必须处理 onChange：若设置 value={state} 但未绑定 onChange，输入框会变成「只读」，因为 React 会强制将输入框值同步为 state，而 state 无法更新。
- 非受控组件的 ref 安全使用：确保在组件挂载后再访问 ref.current，可在 useEffect 或提交事件中使用，避免 null 报错。
- 复选框 / 单选框的特殊处理：
- 受控模式：用 checked={state} 替代 value，绑定 onChange 处理 e.target.checked；
- 非受控模式：用 defaultChecked 初始化，通过 ref.current.checked 获取状态。
- 性能优化建议：
- 受控模式高频输入（如输入框实时搜索）：使用 debounce 延迟 setState，或使用 useCallback 缓存事件处理器；
- 非受控模式海量表单：避免为每个输入框创建 ref，可通过 name 属性批量获取（如 document.getElementsByName）。
- 表单库的选择：复杂表单（如几十上百个字段）建议使用 Formik、React Hook Form 等库，它们封装了受控模式的复杂性，同时提供校验、联动等功能，React Hook Form 还支持非受控模式的性能优势。
六、总结
受控模式与非受控模式并非「谁优谁劣」，而是「场景适配」问题：
- 追求 数据可控性、实时交互、复杂逻辑 → 选择受控模式；
- 追求 简洁性、原生体验、性能优化 → 选择非受控模式。
理解两者的核心差异（数据控制权归属），结合业务场景灵活选择，才能写出高效、可维护的 React 表单代码。实际开发中，简单表单可用非受控模式快速实现，复杂表单建议用受控模式或表单库统一管理，平衡开发效率与产品体验。
