React 表单处理

为什么表单处理是 React 应用的核心能力

表单是 Web 应用与用户交互的基础设施。从登录注册到搜索过滤，从配置面板到内容编辑，几乎所有用户输入场景都离不开表单。然而，React 的声明式 UI 模型与传统的命令式表单操作之间存在天然的 tension——表单状态天然具有瞬时性、频繁更新、跨字段关联等特征，这些特征与 React 的 render 模型并不总是完美契合。

面试定位：表单处理是 React 面试的高频考点。面试官通过候选人对受控/非受控组件的理解、React Hook Form 的使用场景、以及表单验证策略的选择，快速判断候选人是否具备构建复杂交互表单的工程能力。

一、受控组件 vs 非受控组件

1.1 受控组件（Controlled Components）

受控组件的核心特征是：表单数据由 React 组件的状态（state）完全控制。每次用户输入都会触发状态更新，UI 随之重新渲染。

function LoginForm() {
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');

  const handleSubmit = (e) => {
    e.preventDefault();
    console.log({ email, password });
  };

  return (
    <form onSubmit={handleSubmit}>
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        placeholder="邮箱"
      />
      <input
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
        placeholder="密码"
      />
      <button type="submit">登录</button>
    </form>
  );
}

受控组件的工作机制：

用户在 input 中输入内容
onChange 事件触发，读取 e.target.value
调用 setState 更新组件状态
组件重新渲染，input 的 value 属性被赋予新的状态值
用户看到的 UI 反映了最新状态

工程价值：

状态即时可用——输入值在 state 中，任何时候都可以直接使用
易于实现实时验证和格式化（如手机号分段、金额千分位）
适合需要根据用户输入动态调整 UI 的场景（如搜索建议）

1.2 非受控组件（Uncontrolled Components）

非受控组件的核心特征是：表单数据由 DOM 自身管理，React 通过 ref 访问底层 DOM 节点获取值。

function LoginForm() {
  const emailRef = useRef(null);
  const passwordRef = useRef(null);

  const handleSubmit = (e) => {
    e.preventDefault();
    console.log({
      email: emailRef.current.value,
      password: passwordRef.current.value,
    });
  };

  return (
    <form onSubmit={handleSubmit}>
      <input type="email" ref={emailRef} placeholder="邮箱" />
      <input type="password" ref={passwordRef} placeholder="密码" />
      <button type="submit">登录</button>
    </form>
  );
}

非受控组件的工作机制：

React 通过 ref 拿到 DOM 节点的引用
用户输入直接改变 DOM 节点的 value 属性（浏览器原生行为）
组件状态不追踪输入值
提交时通过 ref.current.value 读取表单数据

1.3 两种模式的核心对比

维度	受控组件	非受控组件
数据来源	React state	DOM 自身
取值方式	状态变量	`ref.current.value`
实时访问输入值	直接读取 state	需要读 DOM
动态 UI 响应	天然支持	需要额外机制
性能	每次输入触发 re-render	不触发 re-render
适用场景	需要实时验证/格式化	简单表单、文件上传、第三方控件集成

重要理解：受控/非受控并不是"好/坏"之分，而是不同的数据流模式。受控组件将表单状态纳入 React 的单向数据流中，非受控组件则让 DOM 自行管理状态。在同一个应用中，根据场景选择合适的模式才是工程判断。

二、表单验证策略

2.1 验证的三层位置

表单验证可以在三个不同层次实现，各有优劣：

第一层：HTML5 原生验证

<input
  type="email"
  required
  minlength="6"
  pattern="[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}"
/>

第二层：JavaScript 客户端验证

function validateForm(values) {
  const errors = {};

  if (!values.email) {
    errors.email = '邮箱不能为空';
  } else if (!/\S+@\S+\.\S+/.test(values.email)) {
    errors.email = '邮箱格式不正确';
  }

  if (!values.password) {
    errors.password = '密码不能为空';
  } else if (values.password.length < 8) {
    errors.password = '密码至少8位';
  }

  return errors;
}

第三层：服务端验证

永远不要信任客户端验证——它只是用户体验优化。真正的数据安全在服务端。

2.2 验证时机：即时 vs 提交时

即时验证（On-change validation）：

优点：用户立即得到反馈
缺点：可能干扰用户输入（未完成时就报错）
适用：密码强度、格式校验等即时反馈有价值的场景

提交时验证（On-submit validation）：

优点：不干扰用户输入流程
缺点：用户可能输入了很多才看到错误
适用：非关键信息或复杂跨字段验证

最佳实践：混合策略

function useFormValidation() {
  const [touched, setTouched] = useState({});
  const [errors, setErrors] = useState({});

  const handleBlur = (field) => {
    setTouched(prev => ({ ...prev, [field]: true }));
    // 字段失焦时验证
    const fieldErrors = validateField(field, formValues[field]);
    setErrors(prev => ({ ...prev, [field]: fieldErrors }));
  };

  const handleSubmit = () => {
    const allErrors = validateForm(formValues);
    setErrors(allErrors);
    // 只有全部通过才提交
    if (Object.keys(allErrors).length === 0) {
      submitForm();
    }
  };

  // 只显示已触碰字段的错误
  const visibleErrors = Object.keys(touched).reduce((acc, key) => {
    if (touched[key] && errors[key]) {
      acc[key] = errors[key];
    }
    return acc;
  }, {});

  return { errors: visibleErrors, handleBlur, handleSubmit };
}

这种"触碰后显示错误，提交时全面验证"的策略是很多成熟 UI 库（如 Ant Design、Material-UI）的默认行为。

2.3 验证库的选择

库	特点	适用场景
React Hook Form	轻量、高性能、拥抱非受控	性能敏感的大型表单
Formik	完整、受控组件优先	需要复杂表单逻辑的项目
Yup / Zod	仅验证（需要配合表单库）	需要强类型 schema 的项目

Dan Abramov 在 You Might Not Need an Effect 一文中指出：表单验证逻辑应该尽量放在事件处理器中，而不是 useEffect 中——因为验证是基于用户输入的直接响应，不需要额外的同步机制。

三、React Hook Form 核心用法和使用场景

3.1 核心 API

React Hook Form（后简称 RHF）的核心理念是：让表单状态存在于 DOM 层面，而不是 JavaScript 内存中。这使得它能够大幅减少不必要的 re-render。

import { useForm } from 'react-hook-form';

function LoginForm() {
  const { register, handleSubmit, formState: { errors } } = useForm();

  const onSubmit = (data) => {
    console.log(data); // { email: "...", password: "..." }
  };

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <input {...register('email', { required: '邮箱不能为空' })} />
      {errors.email && <span>{errors.email.message}</span>}

      <input
        {...register('password', {
          required: '密码不能为空',
          minLength: { value: 8, message: '至少8位' }
        })}
      />
      {errors.password && <span>{errors.password.message}</span>}

      <button type="submit">登录</button>
    </form>
  );
}

register 函数将 input 登记到 RHF 的内部注册表中，返回 onChange、onBlur、name、ref 等属性，spread 到 input 上。

3.2 注册机制（Register）

RHF 的 register 支持丰富的配置：

<input
  {...register('username', {
    required: '用户名必填',
    minLength: { value: 3, message: '至少3个字符' },
    maxLength: { value: 20, message: '最多20个字符' },
    pattern: { value: /^[a-zA-Z0-9]+$/, message: '只允许字母数字' },
    validate: {
      notAdmin: (value) => value !== 'admin' || '不能使用 admin 用户名',
      notDuplicate: async (value) => {
        const res = await fetch(`/api/check-username?val=${value}`);
        const { exists } = await res.json();
        return !exists || '用户名已被占用';
      },
    },
  })}
/>

validate 选项支持同步和异步（返回 Promise）验证函数，这是 RHF 的强大特性。

3.3 Controller 组件：桥接受控组件

对于非原生 input 组件（如第三方 DatePicker、Select），RHF 提供了 Controller 组件：

import { Controller, useForm } from 'react-hook-form';
import DatePicker from 'react-datepicker';

function DateForm() {
  const { control, handleSubmit } = useForm();

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      <Controller
        name="startDate"
        control={control}
        rules={{ required: '请选择开始日期' }}
        render={({ field }) => (
          <DatePicker
            selected={field.value}
            onChange={field.onChange}
            onBlur={field.onBlur}
          />
        )}
      />
      <button type="submit">提交</button>
    </form>
  );
}

Controller 的本质是将非受控组件适配为 RHF 的受控注册接口——它接管组件的 value、onChange、onBlur，使它们符合 RHF 的内部契约。

3.4 Schema 验证（with Zod）

RHF 支持与 Zod、Yup 等 schema 验证库配合，实现声明式验证：

import { zodResolver } from '@hookform/resolvers/zod';
import { z } from 'zod';

const schema = z.object({
  email: z.string().email('邮箱格式不正确'),
  password: z.string().min(8, '至少8位'),
});

function LoginForm() {
  const {
    register,
    handleSubmit,
    formState: { errors },
  } = useForm({
    resolver: zodResolver(schema),
  });

  // ...
}

Zod 的优势在于运行时验证 + TypeScript 类型推导一体化——schema 既是验证规则，也是类型定义。

3.5 性能优化：skip рядный re-render

RHF 默认使用非受控模式，这带来了独特的性能优势：

// RHF 的 re-render 范围 vs 受控表单库
// 场景：用户输入，100个字段的表单

// 受控表单库（Formik）：每次输入触发整个表单 re-render
// React Hook Form：只在当前字段附近触发最小范围 re-render

但 RHF 也支持 useForm 的 mode 选项控制验证时机：

useForm({
  mode: 'onChange',    // 输入变化时验证（性能开销大）
  mode: 'onBlur',      // 失焦时验证（推荐）
  mode: 'onSubmit',    // 只在提交时验证（默认）
  mode: 'onTouched',   // 触碰后（失焦）验证，后续输入不再验证
});

3.6 RHF 的适用场景判断

适合使用 RHF 的场景：

表单字段数量多（>10个字段）
表单性能敏感（高频输入、长列表渲染）
需要集成第三方输入组件
团队熟悉 React Hooks 模式

不适合使用 RHF（或考虑受控模式更优）的场景：

简单表单（3-5个字段，受控模式更直观）
需要复杂跨字段实时计算（如购物车实时总价）
表单状态需要与其他组件共享

四、为什么要用非受控组件

4.1 文件上传

文件 input 是非受控组件最典型的使用场景——文件数据无法且不应该存储在 React state 中：

function FileUpload() {
  const fileRef = useRef(null);
  const [preview, setPreview] = useState(null);

  const handleFileChange = (e) => {
    const file = e.target.files[0];
    if (file) {
      const reader = new FileReader();
      reader.onloadend = () => setPreview(reader.result);
      reader.readAsDataURL(file);
    }
  };

  const handleSubmit = async (e) => {
    e.preventDefault();
    const formData = new FormData();
    formData.append('file', fileRef.current.files[0]);
    await fetch('/api/upload', { method: 'POST', body: formData });
  };

  return (
    <form onSubmit={handleSubmit}>
      <input type="file" ref={fileRef} onChange={handleFileChange} />
      {preview && <img src={preview} alt="预览" />}
      <button type="submit">上传</button>
    </form>
  );
}

这里的 fileRef.current.files[0] 读取的是浏览器封装的 File 对象，这是 DOM 的固有特性，React 的 state 模型并不适合表达它。

4.2 第三方控件集成

许多第三方 UI 库（日期选择器、富文本编辑器、地图控件）封装了自己的内部状态管理。对这类控件使用受控模式意味着你要把第三方控件的内部状态同步到 React state，两套状态系统叠加会导致复杂度爆炸：

// 第三方日期选择器：受控模式（不推荐）
const [date, setDate] = useState(null);

// 第三方富文本编辑器：受控模式（不推荐）
const [content, setContent] = useState('');

// 两者都需要你手动同步状态，而第三方控件自己也有内部状态

正确做法是非受控集成——通过 ref 访问控件值，只在真正需要的时候（如提交时）读取：

const datePickerRef = useRef(null);
const editorRef = useRef(null);

const handleSubmit = () => {
  const date = datePickerRef.current?.getValue();
  const content = editorRef.current?.getContent();
  // 提交到服务器
};

4.3 性能敏感场景

对于超大型表单（如配置面板、数据录入页面），如果每个字段都用受控模式，每次击键都会触发整个表单的 re-render。使用非受控组件可以减少 re-render 次数：

// 受控模式：每次击键 → 触发包含所有字段的重新渲染
// 非受控模式：击键 → 只更新 DOM 的 value 属性，不触发 React re-render

RHF 的高性能正是利用了这一特性——它让表单状态"存在于 DOM 中"，只在必要时才同步到 React。

五、表单提交和数据处理

5.1 提交处理的通用模式

async function handleSubmit(asyncFn) {
  const isValid = await trigger(); // 触发验证
  if (!isValid) return;

  const formData = getValues(); // 获取所有字段值
  try {
    setIsSubmitting(true);
    await asyncFn(formData);
    onSuccess(); // 成功后的回调（如跳转、重置）
  } catch (err) {
    handleServerError(err); // 处理服务端错误（如用户名已存在）
  } finally {
    setIsSubmitting(false);
  }
}

5.2 数据转换和格式化

表单数据通常需要经过转换才能发送到 API：

// 原始表单数据
const rawValues = {
  birthDate: Date,          // Date 对象
  notifyBy: ['email'],      // 数组
  acceptTerms: true,        // boolean
};

// 转换为 API 期望的格式
const apiPayload = {
  birth_date: formatDate(rawValues.birthDate, 'YYYY-MM-DD'),
  notify_by: rawValues.notifyBy.join(','),
  accept_terms: rawValues.acceptTerms ? 1 : 0,
};

RHF 的 transform 选项可以在注册时直接定义转换：

<input
  {...register('birthDate', {
    setValueAs: (value) => value ? new Date(value) : null,
  })}
/>

5.3 服务端错误处理

服务端验证失败时，需要将错误回填到表单：

const { setError, formState: { errors } } = useForm();

// 服务端返回 422 错误
if (err.status === 422) {
  const { errors: serverErrors } = await err.json();
  Object.entries(serverErrors).forEach(([field, message]) => {
    setError(field, { type: 'server', message });
  });
}

5.4 表单重置

表单重置不仅是清空数据，还包括重置验证状态和触碰状态：

const { reset, formState: { isSubmitSuccessful } } = useForm();

useEffect(() => {
  if (isSubmitSuccessful) {
    reset({}, { keepValues: false, keepErrors: false });
  }
}, [isSubmitSuccessful, reset]);

RHF 的 reset 函数支持精细控制——哪些状态要保留，哪些要重置。

六、受控/非受控混合模式

6.1 为什么需要混合模式

实际业务中，很多表单既需要非受控的性能优势，又需要在特定时机"接管"控制权：

function SearchForm() {
  const [isEditing, setIsEditing] = useState(false);
  const { register, handleSubmit, setValue, reset } = useForm();

  // 初始值从 API 加载（受控设置）
  useEffect(() => {
    fetchSearchConfig().then(config => {
      setValue('keywords', config.keywords);
      setValue('filters', config.filters);
    });
  }, [setValue]);

  const onSubmit = (data) => {
    updateSearchConfig(data);
    setIsEditing(false);
  };

  return (
    <form onSubmit={handleSubmit(onSubmit)}>
      {/* 非受控模式：用户输入时不需要 re-render */}
      <input {...register('keywords')} />

      {/* 复杂过滤器用 Controller 接入 */}
      <Controller
        name="filters"
        control={control}
        render={({ field }) => <FilterPanel {...field} />}
      />

      {isEditing ? (
        <button type="submit">保存</button>
      ) : (
        <button type="button" onClick={() => setIsEditing(true)}>编辑</button>
      )}
    </form>
  );
}

6.2 混合模式的工程判断

混合模式增加了复杂度，是否值得使用需要权衡：

值得混合的场景：性能敏感的大型表单，且有部分字段需要特殊处理（初始值填充、联动计算）
不值得混合的场景：表单简单，团队对 React 表单模型理解不深——混合模式容易成为过度工程的温床

七、面试高频问题

Q: 受控组件和非受控组件的区别是什么？如何选择？

回答要点：受控组件的数据由 React state 管理，每次输入触发 re-render；非受控组件由 DOM 管理数据，通过 ref 取值。选择依据是场景特征：需要实时验证/格式化/联动时用受控；文件上传、第三方控件、性能敏感的大型表单用非受控。两者不是对立关系，而是互补——很多复杂表单需要混合使用。

Q: React Hook Form 为什么性能好？

回答要点：RHF 核心使用非受控模式——表单状态存在于 DOM 节点上而非 React state。这意味着每次用户输入只更新 DOM 的 value 属性，不触发组件 re-render。只有当开发者明确需要"在 React 中使用表单数据"时（如显示错误、提交数据），才会触发 re-render。对比之下，传统的受控表单库每次输入都会触发整个表单的 re-render。

Q: 为什么文件上传通常用非受控组件？

回答要点：<input type="file"> 的 files 属性返回 FileList，这是浏览器的 File API 封装，不适合也不应该存在 React state 中。而且文件数据可能很大（图片预览、视频），存入 state 会导致严重的性能问题。通过 ref 直接读取 files[0] 是最自然的方式。

延展阅读

React 官方文档：表单 — React 官方对受控/非受控组件的解释
React Hook Form 官方文档 — RHF 的完整 API 文档和使用指南
Dan Abramov: You Might Not Need an Effect — 表单验证逻辑应该放在事件处理器中而非 useEffect
Kent C. Dodds: Form validation in React — 深入讲解 RHF 的验证模式
React Hook Form 性能优化指南 — 官方性能指南