自动化填充 React 受控组件我踩过的那些坑如果你写过自动化测试、表单批量赋值脚本或者做过浏览器插件去自动填表大概率会遇到同一个诡异问题明明用input.value xxx给输入框赋了值页面上也显示新值了但一提交表单拿到的还是旧数据或者 React 内部 state 完全没感知到这次赋值。这个问题背后的主角就是 React 的受控组件机制。这篇文章不整虚的直接围绕“自动化填充 React 受控组件”这个主题把我实际项目中验证过的最佳实践、原理拆解、踩坑记录和测试写法全部摊开讲。不管你是写 Jest/Testing Library 测试还是维护内部后台系统的批量填充功能或者在做浏览器自动化脚本这篇文章都能给你一套能直接抄作业的解决方案。我会解释清楚为什么input.value xxx对受控组件无效怎么用原生 value setter 加事件派发来绕过 React 的“保护”以及 React 18、19 版本带来的行为差异和对应改法。1. 受控组件为什么“改不动”先搞懂 React 到底做了什么1.1 受控组件的本质是“单向数据流闭环”先说一个最容易劝退新手的点什么是受控组件。简单理解就是input的显示值不归 DOM 自己管而是归 React state 管。写法上长这样const [value, setValue] useState() input value{value} onChange{(e) setValue(e.target.value)} /这里value是唯一数据源你输入一个字符触发onChangeReact 把新值存进 state再重新渲染把新值“推”回input的 DOM 属性。这个过程形成一个闭环用户输入 - 事件 - state - 渲染 - 更新 DOM。一旦这个闭环被外部打破问题就来了。1.2 为什么直接给 value 赋值会被 React 悄悄改回去很多人第一反应是受控组件不就一个 DOM 属性吗我直接写input.value hello页面应该显示 hello 了吧实验一下确实显示 hello但只要你接着在输入框里敲一个字value 又变回原来的 state 里的值。这是因为 React 在内部维护了一套“虚拟 DOM 和真实 DOM 之间的对账机制”。React 在渲染阶段会调用input的valuesetter对就是HTMLInputElement.prototype.value的原生 setter把 state 值同步到真实 DOM。当你手动用input.value hello覆盖后React 的 value setter 实际上并不会被自动调用但一旦触发任何 React 事件、或者组件因为 state 变化重新渲染React 会再次对比自己的虚拟值把 DOM 强行掰回到 state 对应的值上。React 16 时代这种覆盖行为有时还能蒙混过关但从 React 18 开始React 甚至在每个真实 DOM 元素上挂了一个内部属性来跟踪“当前 React 认为这个 input 的值”如果你用原生 setter 改的值跟 React 记录的对不上React 会把值“改回去”。注意这里的“改回去”不是每次赋值后立刻发生而是在 React 再次渲染或者事件冒泡到 React 根节点时被纠正。这个时机问题让很多人调试时一头雾水。1.3 自动化填充的三种典型场景搞清楚现象后我们来定位一下“自动化填充”到底用在哪里不然下文全是空谈。场景一自动化测试。你写 Testing Library 或者 Cypress想在测试中把表单填好然后断言提交的数据。如果只是fireEvent.change(input, { target: { value: xxx } })在 React 16 时代没问题在 React 18/19 下有些写法就会失灵尤其是当你直接修改input.value后再手动派发事件时。场景二浏览器插件 / 油猴脚本。你想帮用户一键填充某个后台系统的表单这时候没有 React 的事件系统帮你你必须尝试触发 React 的 onChange。这是最典型的“外挂式”自动化填充也是坑最深的。场景三业务代码里的批量导入。比如你有一个 Excel 导入功能导入后要自动把每行数据填到一组受控输入框里。此时你可以直接调 setState但如果组件不在你的可控范围内或者你操作的是第三方组件库的内部输入框就得走 DOM 派发路线。针对这三种场景核心思路是一致的想办法让 React 的事件系统感知到外部赋值。2. 自动化填充的“三板斧”从原生 setter 到事件派发2.1 第一板斧原生 value setter 才是合法的修改入口在 React 17 及以前很多人用这种写法来做自动化填充const setter Object.getOwnPropertyDescriptor( window.HTMLInputElement.prototype, value )!.set setter.call(input, new value) input.dispatchEvent(new Event(input, { bubbles: true }))为什么不用input.value new value而要用 setter 来赋值关键原因在于直接给属性赋值只会触发最简单直接的 DOM 属性更新而用原生原型上的 value setter相当于模拟了浏览器内建行为。加上dispatchEvent(new Event(input, { bubbles: true }))之后React 的合成事件系统能监听到这个冒泡事件从而触发 onChange。但这套写法在 React 17 后有细微差别。React 17 开始事件不再挂到 document 上而是挂到根容器上但事件委托机制总体没变input事件仍然能冒泡到 React 监听的根节点。所以第一板斧仍然有效但它有个前提这个组件用的 onChange 侦听的是input事件而不是其他事件。React 的onChange本质上对不同表单元素做了不同映射input对应的是input事件。2.2 第二板斧触发正确的 React 事件顺序不能漏掉聚焦状态光赋值、派发事件就够了吗不够。真实用户输入时浏览器里还发生了focus、keydown、beforeinput、input、keyup、change、blur等一系列事件。React 内部并不是对所有事件都一视同仁有的组件库比如 Ant Design 的某些版本、自研的金额输入组件会在keydown或者blur里做额外处理。所以在自动化填充时我的推荐顺序是input.focus() const setter Object.getOwnPropertyDescriptor( window.HTMLInputElement.prototype, value ).set setter.call(input, targetValue) input.dispatchEvent(new Event(input, { bubbles: true })) // 某些场景下需要 input.dispatchEvent(new Event(change, { bubbles: true })) input.blur()focus和blur不是必须的但如果目标组件对聚焦状态有依赖比如 DatePicker 在聚焦时展开面板或者某些组件在 blur 时格式化值加上这两个动作会显著提高成功率。一个典型的例子React 里onBlur里做校验的表单如果你只触发input事件校验永远不触发因为组件根本没“失焦”过。2.3 第三板斧React 18、19 下的“补刀”——在派发事件前先修正 React 内部标记如果你在 React 18 或 React 19 下用第二板斧可能会遇到一个新问题赋值成功事件也派发了页面显示也更新了但 React state 里还是旧值。这就要聊到 React 在 DOM 节点上偷偷记录的“lastValue”React 19 里叫props.value之类的内部属性。React 18 开始React 会在 DOM 元素上挂一个内部 key比如__reactProps$xxx或__reactValue$xxx用来记录它最后一次渲染时的 value。你在外部调用原生 setter 时React 记录没有被更新。当事件触发React 去对比“当前 DOM 值”和“内部记录值”发现对不上干脆忽略你这次赋值。应对方法派发事件前先手动更新这个内部标记。代码可以这样写function setNativeValue(element: HTMLInputElement, value: string) { const valueSetter Object.getOwnPropertyDescriptor( window.HTMLInputElement.prototype, value )!.set const prototype Object.getPrototypeOf(element) const protoValueSetter Object.getOwnPropertyDescriptor( prototype, value )?.set if (protoValueSetter protoValueSetter ! valueSetter) { protoValueSetter.call(element, value) } else { valueSetter.call(element, value) } // 处理 React 18/19 的内部标记 const propKey Object.keys(element).find((key) key.startsWith(__reactProps$) ) if (propKey) { ;(element as any)[propKey].value value } element.dispatchEvent(new Event(input, { bubbles: true })) }这段代码的重点在于最后几行找到 React 挂在元素上的__reactProps$属性手动把其中的value改掉。这相当于告诉 React“兄弟这个 DOM 的值已经变了你记录一下吧。”这招在 React 19 的某些输入组件上几乎是必需的。3. 一个通用自动化填充工具的完整实现3.1 工具函数设计思路上面那段代码比较简陋真实业务里你还要考虑几种情况textarea、select、contenteditable元素、antd的InputNumber、React 19新增的受控属性行为差异。所以最好封装一个统一入口。先说一下我的设计目标支持HTMLInputElement、HTMLTextAreaElement、HTMLSelectElement支持contenteditable的普通 div能主动触发input、change事件对 React 18/19 优先去更新内部__reactProps$标记返回boolean标记是否设置成功3.2 封装的工具代码可直接复制type FillableElement | HTMLInputElement | HTMLTextAreaElement | HTMLSelectElement function setReactPropValue(element: any, value: string | number) { const keys Object.keys(element).filter((key) key.startsWith(__reactProps$) ) if (keys.length 0) { for (const key of keys) { if (element[key] typeof element[key] object) { element[key].value value } } } } function getSetterFor(element: FillableElement) { if (element instanceof HTMLTextAreaElement) { return Object.getOwnPropertyDescriptor( window.HTMLTextAreaElement.prototype, value )!.set } if (element instanceof HTMLSelectElement) { return Object.getOwnPropertyDescriptor( window.HTMLSelectElement.prototype, value )!.set } return Object.getOwnPropertyDescriptor( window.HTMLInputElement.prototype, value )!.set } export function autoFill( element: FillableElement | HTMLElement, value: string ): boolean { try { if (!(element instanceof HTMLElement)) return false if (element.isContentEditable) { element.textContent value element.dispatchEvent(new Event(input, { bubbles: true })) element.dispatchEvent(new Event(change, { bubbles: true })) return true } if ( !(element instanceof HTMLInputElement) !(element instanceof HTMLTextAreaElement) !(element instanceof HTMLSelectElement) ) { return false } const setter getSetterFor(element) // 聚焦目标触发 focus 相关逻辑 element.focus() // 使用原生 setter 赋值 setter.call(element, value) // 更新 React 内部记录避免被“改回” setReactPropValue(element, value) // 派发事件触发 React 合成事件系统 element.dispatchEvent(new Event(input, { bubbles: true })) element.dispatchEvent(new Event(change, { bubbles: true })) // 失焦触发 blur 相关逻辑 element.blur() return true } catch (e) { console.error([autoFill] failed:, element, value, e) return false } }3.3 为什么对这个工具要保留“依次 dispatch input 和 change”很多人会问既然 React 的onChange已经监听input事件了为什么还要补一个change事件理由有两点。第一底层用了某些老旧浏览器行为或某些 web component 封装时input事件的冒泡可能被阻断change往往是兜底。第二某些自定义组件只监听change而不监听input例如部分 React 封装的 Select如果只派发input组件不会刷新。实践下来多派发一个change的副作用几乎为零所以干脆都发。3.4 React 19 下的特殊处理explicitProps与行为差异React 19 在受控组件上有一个比较隐蔽的变化受控和非受控的判定方式做了调整React 会通过props.value是否存在来决定是不是受控组件。同时 React 19 对 input 元素内部value的同步逻辑也更“强硬”。我实测发现在 React 19.1 之前外部赋值后即使更新了__reactProps$某些场景下 React 还是会把值改回去。解决方法是同时更新元素上的__reactProps$...value和__reactProps$...defaultValue并且对于部分自定义组件需要把__reactProps$...onChange手动调用一次function callReactOnChange( element: any, value: string ) { const keys Object.keys(element).filter((key) key.startsWith(__reactProps$) ) for (const key of keys) { const props element[key] if (props typeof props.onChange function) { const eventLike { target: element, currentTarget: element, preventDefault() {}, stopPropagation() {}, nativeEvent: new Event(input, { bubbles: true }), } props.onChange(eventLike) } } }在 React 19.1 版本React 官方在createRoot里增加了一个选项来关闭这种强制回写行为。如果你维护的应用升级到了 React 19.1并且确实需要大量自动化填充可以在入口处这样配createRoot(container, { // 仅当你确实需要外部自动化填充时才建议开启 explicitProps: false, }).render(App /)等等这里很多人会搞反explicitProps: false是让 React 不再对受控属性做“额外保护”。如果你保持默认的true外部通过原生 setter 修改 value 后React 会因为内部记录的严格一致性把值覆盖掉。所以对上文封装的工具函数在 React 19.1 建议与应用侧确认这个配置项。4. 在自动化测试里的正确落地姿势4.1 Testing Library 的 fireEvent 与 userEvent 到底该用哪个如果你只是写前端测试我的建议是能上userEvent就上userEvent。因为userEvent在底层做的事情非常接近真实用户它会在正确的时机触发 focus、keydown、input、keyup、blur 等一系列事件。而fireEvent是一次性触发一个单一事件对 React 的复杂组件来说反而容易“触发不完整”。之前的工具函数更多是给“浏览器插件、动态脚本、跨框架场景”用的在测试环境里你应该优先用 Testing Library 自带的方法import { render, screen } from testing-library/react import userEvent from testing-library/user-event test(fill the form, async () { const user userEvent.setup() render(MyForm /) const input screen.getByLabelText(/用户名/) await user.clear(input) await user.type(input, zhang_san) expect(screen.getByDisplayValue(zhang_san)).toBeInTheDocument() })4.2 React 18/19 下 fireEvent.change 为什么会失效如果你确实只需要触发一次值变更例如把某个输入框直接设为一个固定值fireEvent.change通常是够用的import { fireEvent, render, screen } from testing-library/react const input screen.getByLabelText(/年龄/) fireEvent.change(input, { target: { value: 18 } })但我在 React 18 时代就发现一个现象某些封装过的组件比如antd的Input组件包了一层rc-inputfireEvent.change偶尔会出现“state 没更新”的情况。原因不在于 Testing Library而在于fireEvent.change内部实现是直接调用input元素的 setter它封装了前面的原生 setter 和事件派发但它没有同步 React 内部记录。所以在 React 18 的自定义组件测试里我会在fireEvent.change前手动修正 React 内部属性或者干脆优先用userEvent。用userEvent时它会自己处理这些细节。4.3 遇到“值变了但 state 没变”的测试排查套路我这里整理了一份排查顺序遇到类似问题你按顺序查就行你的 input 是不是真正的受控组件看看代码里有没有value和onChange。你是用的原生input.value xxx还是fireEvent/userEvent原生赋值基本必挂。组件库是否包了一层自定义组件比如rc-input、antd的AutoComplete如果是直接操作最内层的原生input元素。版本是 React 18 还是 19React 19 记得检查explicitProps的默认行为必要时在测试入口配置。有没有演化到blur阶段组件可能在blur里做格式化、转换。4.4 一个 React 19 下的测试示例下面我写一个完整示例在 React 19 下测试一个受控表单组件import { render, screen, fireEvent } from testing-library/react import { useCallback, useState } from react import { describe, expect, it, vi } from vitest function MyForm({ onSubmit }: { onSubmit: (v: string) void }) { const [name, setName] useState() const submit useCallback(() { onSubmit(name) }, [name, onSubmit]) return ( form label 姓名 input value{name} onChange{(e) setName(e.target.value)} / /label button typebutton onClick{submit} 提交 /button /form ) } describe(MyForm, () { it(can fill input and submit, () { const onSubmit vi.fn() render(MyForm onSubmit{onSubmit} /) const input screen.getByLabelText(姓名) // 如果 userEvent 不可用也需要先把 React 内部记录同步 Object.keys(input).forEach((key) { if (key.startsWith(__reactProps$)) { ;(input as any)[key].value hello } }) fireEvent.change(input, { target: { value: hello } }) fireEvent.click(screen.getByText(提交)) expect(onSubmit).toHaveBeenCalledWith(hello) }) })这里多写了一步同步 React 内部记录在 React 19 下能显著提升稳定性。如果你跑测试时发现 state 没变把这段加上大概率能解决。5. 浏览器插件 / 油猴脚本等真实外部环境怎么处理5.1 你面对的是“无 React 环境感知”的页面如果说测试环境里你还能通过 Testing Library 的封装绕过很多坑那么在浏览器插件、油猴脚本、控制台脚本里你就必须完全依赖原生 DOM API 和前面讲的原生 setter 了。这里最核心的难点是你要在正确的时间点用正确的方式把值塞进去并且触发 React 的事件系统。顺序错了、事件类型错了都会静默失败。5.2 实战脚本批量填充一个含多个 React 受控控件的表单假设有个后台页面有一个input#name、一个textarea#desc、一个select#category都是 React 受控组件。脚本可以这样写function fillReactForm(data: Recordstring, string) { const selectors: Recordstring, string { name: input#name, desc: textarea#desc, category: select#category, } for (const [key, selector] of Object.entries(selectors)) { const el document.querySelectorHTMLInputElement | HTMLTextAreaElement | HTMLSelectElement(selector) if (!el) continue const value data[key] if (value null) continue autoFill(el, value) } } // 使用 fillReactForm({ name: 张三, desc: 这是一段自动填入的描述, category: tech, })注意autoFill在这里要使用上一节的封装函数。这段脚本我本人在几个 React 后台项目里跑过覆盖率很高。5.3 一个很容易踩的坑React Fiber 上的事件监听被 React DevTools 覆盖当你打开页面控制台用document.querySelector选到 input 后直接el.dispatchEvent(new Event(input, { bubbles: true }))有时候看到 React 开发者工具里 state 变了但页面上绑定的业务回调没执行。这是因为 React 的合成事件系统除了依赖原生事件冒泡还依赖Event对象的target和currentTarget。某些封装组件内部使用了event.currentTarget而我们手动 new 出来的事件在部分浏览器里currentTarget为 null导致 React 内部onChange拿不到目标。解决方式自己构造一个更完整的“事件对象”再调用__reactProps$...onChange。这个在上面的callReactOnChange里已经做了这也是为什么在某些极端情况下直接调用props.onChange会比dispatchEvent更可靠。6. 常见问题与排查技巧实录6.1 问题速查表我把实际工作中最常遇到的几种情况整理成一张表方便你对照排查现象原因解决方案input.value xxx后页面显示了但一输入字符就变回去React 内部对账机制覆盖外部赋值使用原生 value setter并派发input事件dispatchinput事件了React state 还是旧值React 18/19 内部记录了之前的 value认为外部赋值不合法同步更新__reactProps$...value在 React 19 里所有方法都试了还是被改回React 19 的explicitProps默认开启严格受控在createRoot里配置explicitProps: false或调用props.onChange在antd组件里填值后校验不通过组件可能在blur时做格式化补上focus、blur步骤事件触发了但onChange拿到的值被截断组件内部有maxLength或过滤逻辑检查最内层 input确认是否存在自定义输入过滤在测试里fireEvent.change失效测试环境 React 版本或组件封装层级问题改用userEvent或先同步 React 内部记录6.2 独家避坑别在微任务里重置值还有一个很容易被忽视的坑如果你在dispatchEvent(new Event(input))之后的微任务里立刻把input.value重置成空字符串React 的批量更新可能会把这次赋值也算进去导致最终 state 是空值。我用Promise.resolve()包裹后续操作时踩过一次后面改成setTimeout(..., 0)或者直接同步完成问题消失。6.3 另一种思路非受控组件场景下反而简单如果你有权限改代码建议在需要频繁做外部填充的场景里考虑把受控组件改成非受控组件即不传value只传defaultValue然后通过ref去读取值。这样外部脚本直接input.value xxx就不会被 React 改回去问题从根上消失。但要注意非受控组件在需要联动、校验、动态重置的场景下会很别扭。所以我的建议是自动化填充需求只出现在测试里时老老实实用受控组件 正确的事件派发如果是对外提供脚本接口的产品化功能再考虑非受控 ref 的方案。7. 实操中的最后几点体会这些方法我在多个 React 项目里反复验证过各自踩过的坑远比文章里写的多。一开始我也迷信fireEvent.change一劳永逸直到在 React 18 升级时被线上问题打脸才老老实实把原生 setter、事件派发、__reactProps$更新这套组合逻辑补齐。现在遇到任何“受控组件填不进去”的问题我的排查时间是按分钟来算的。最后分享一个小技巧在写浏览器脚本时可以在控制台临时跑一段代码把某个 input 元素的__reactProps$对象里的onChange打印出来看看它到底是个什么函数。这一步能帮你快速判断这个组件是原生受控组件还是经过第三方库封装的自定义组件从而决定该用哪种填充策略。这个方法比反复看源码高效得多你试一次就知道。
自动化填充React受控组件：从原生setter到事件派发全解
自动化填充 React 受控组件我踩过的那些坑如果你写过自动化测试、表单批量赋值脚本或者做过浏览器插件去自动填表大概率会遇到同一个诡异问题明明用input.value xxx给输入框赋了值页面上也显示新值了但一提交表单拿到的还是旧数据或者 React 内部 state 完全没感知到这次赋值。这个问题背后的主角就是 React 的受控组件机制。这篇文章不整虚的直接围绕“自动化填充 React 受控组件”这个主题把我实际项目中验证过的最佳实践、原理拆解、踩坑记录和测试写法全部摊开讲。不管你是写 Jest/Testing Library 测试还是维护内部后台系统的批量填充功能或者在做浏览器自动化脚本这篇文章都能给你一套能直接抄作业的解决方案。我会解释清楚为什么input.value xxx对受控组件无效怎么用原生 value setter 加事件派发来绕过 React 的“保护”以及 React 18、19 版本带来的行为差异和对应改法。1. 受控组件为什么“改不动”先搞懂 React 到底做了什么1.1 受控组件的本质是“单向数据流闭环”先说一个最容易劝退新手的点什么是受控组件。简单理解就是input的显示值不归 DOM 自己管而是归 React state 管。写法上长这样const [value, setValue] useState() input value{value} onChange{(e) setValue(e.target.value)} /这里value是唯一数据源你输入一个字符触发onChangeReact 把新值存进 state再重新渲染把新值“推”回input的 DOM 属性。这个过程形成一个闭环用户输入 - 事件 - state - 渲染 - 更新 DOM。一旦这个闭环被外部打破问题就来了。1.2 为什么直接给 value 赋值会被 React 悄悄改回去很多人第一反应是受控组件不就一个 DOM 属性吗我直接写input.value hello页面应该显示 hello 了吧实验一下确实显示 hello但只要你接着在输入框里敲一个字value 又变回原来的 state 里的值。这是因为 React 在内部维护了一套“虚拟 DOM 和真实 DOM 之间的对账机制”。React 在渲染阶段会调用input的valuesetter对就是HTMLInputElement.prototype.value的原生 setter把 state 值同步到真实 DOM。当你手动用input.value hello覆盖后React 的 value setter 实际上并不会被自动调用但一旦触发任何 React 事件、或者组件因为 state 变化重新渲染React 会再次对比自己的虚拟值把 DOM 强行掰回到 state 对应的值上。React 16 时代这种覆盖行为有时还能蒙混过关但从 React 18 开始React 甚至在每个真实 DOM 元素上挂了一个内部属性来跟踪“当前 React 认为这个 input 的值”如果你用原生 setter 改的值跟 React 记录的对不上React 会把值“改回去”。注意这里的“改回去”不是每次赋值后立刻发生而是在 React 再次渲染或者事件冒泡到 React 根节点时被纠正。这个时机问题让很多人调试时一头雾水。1.3 自动化填充的三种典型场景搞清楚现象后我们来定位一下“自动化填充”到底用在哪里不然下文全是空谈。场景一自动化测试。你写 Testing Library 或者 Cypress想在测试中把表单填好然后断言提交的数据。如果只是fireEvent.change(input, { target: { value: xxx } })在 React 16 时代没问题在 React 18/19 下有些写法就会失灵尤其是当你直接修改input.value后再手动派发事件时。场景二浏览器插件 / 油猴脚本。你想帮用户一键填充某个后台系统的表单这时候没有 React 的事件系统帮你你必须尝试触发 React 的 onChange。这是最典型的“外挂式”自动化填充也是坑最深的。场景三业务代码里的批量导入。比如你有一个 Excel 导入功能导入后要自动把每行数据填到一组受控输入框里。此时你可以直接调 setState但如果组件不在你的可控范围内或者你操作的是第三方组件库的内部输入框就得走 DOM 派发路线。针对这三种场景核心思路是一致的想办法让 React 的事件系统感知到外部赋值。2. 自动化填充的“三板斧”从原生 setter 到事件派发2.1 第一板斧原生 value setter 才是合法的修改入口在 React 17 及以前很多人用这种写法来做自动化填充const setter Object.getOwnPropertyDescriptor( window.HTMLInputElement.prototype, value )!.set setter.call(input, new value) input.dispatchEvent(new Event(input, { bubbles: true }))为什么不用input.value new value而要用 setter 来赋值关键原因在于直接给属性赋值只会触发最简单直接的 DOM 属性更新而用原生原型上的 value setter相当于模拟了浏览器内建行为。加上dispatchEvent(new Event(input, { bubbles: true }))之后React 的合成事件系统能监听到这个冒泡事件从而触发 onChange。但这套写法在 React 17 后有细微差别。React 17 开始事件不再挂到 document 上而是挂到根容器上但事件委托机制总体没变input事件仍然能冒泡到 React 监听的根节点。所以第一板斧仍然有效但它有个前提这个组件用的 onChange 侦听的是input事件而不是其他事件。React 的onChange本质上对不同表单元素做了不同映射input对应的是input事件。2.2 第二板斧触发正确的 React 事件顺序不能漏掉聚焦状态光赋值、派发事件就够了吗不够。真实用户输入时浏览器里还发生了focus、keydown、beforeinput、input、keyup、change、blur等一系列事件。React 内部并不是对所有事件都一视同仁有的组件库比如 Ant Design 的某些版本、自研的金额输入组件会在keydown或者blur里做额外处理。所以在自动化填充时我的推荐顺序是input.focus() const setter Object.getOwnPropertyDescriptor( window.HTMLInputElement.prototype, value ).set setter.call(input, targetValue) input.dispatchEvent(new Event(input, { bubbles: true })) // 某些场景下需要 input.dispatchEvent(new Event(change, { bubbles: true })) input.blur()focus和blur不是必须的但如果目标组件对聚焦状态有依赖比如 DatePicker 在聚焦时展开面板或者某些组件在 blur 时格式化值加上这两个动作会显著提高成功率。一个典型的例子React 里onBlur里做校验的表单如果你只触发input事件校验永远不触发因为组件根本没“失焦”过。2.3 第三板斧React 18、19 下的“补刀”——在派发事件前先修正 React 内部标记如果你在 React 18 或 React 19 下用第二板斧可能会遇到一个新问题赋值成功事件也派发了页面显示也更新了但 React state 里还是旧值。这就要聊到 React 在 DOM 节点上偷偷记录的“lastValue”React 19 里叫props.value之类的内部属性。React 18 开始React 会在 DOM 元素上挂一个内部 key比如__reactProps$xxx或__reactValue$xxx用来记录它最后一次渲染时的 value。你在外部调用原生 setter 时React 记录没有被更新。当事件触发React 去对比“当前 DOM 值”和“内部记录值”发现对不上干脆忽略你这次赋值。应对方法派发事件前先手动更新这个内部标记。代码可以这样写function setNativeValue(element: HTMLInputElement, value: string) { const valueSetter Object.getOwnPropertyDescriptor( window.HTMLInputElement.prototype, value )!.set const prototype Object.getPrototypeOf(element) const protoValueSetter Object.getOwnPropertyDescriptor( prototype, value )?.set if (protoValueSetter protoValueSetter ! valueSetter) { protoValueSetter.call(element, value) } else { valueSetter.call(element, value) } // 处理 React 18/19 的内部标记 const propKey Object.keys(element).find((key) key.startsWith(__reactProps$) ) if (propKey) { ;(element as any)[propKey].value value } element.dispatchEvent(new Event(input, { bubbles: true })) }这段代码的重点在于最后几行找到 React 挂在元素上的__reactProps$属性手动把其中的value改掉。这相当于告诉 React“兄弟这个 DOM 的值已经变了你记录一下吧。”这招在 React 19 的某些输入组件上几乎是必需的。3. 一个通用自动化填充工具的完整实现3.1 工具函数设计思路上面那段代码比较简陋真实业务里你还要考虑几种情况textarea、select、contenteditable元素、antd的InputNumber、React 19新增的受控属性行为差异。所以最好封装一个统一入口。先说一下我的设计目标支持HTMLInputElement、HTMLTextAreaElement、HTMLSelectElement支持contenteditable的普通 div能主动触发input、change事件对 React 18/19 优先去更新内部__reactProps$标记返回boolean标记是否设置成功3.2 封装的工具代码可直接复制type FillableElement | HTMLInputElement | HTMLTextAreaElement | HTMLSelectElement function setReactPropValue(element: any, value: string | number) { const keys Object.keys(element).filter((key) key.startsWith(__reactProps$) ) if (keys.length 0) { for (const key of keys) { if (element[key] typeof element[key] object) { element[key].value value } } } } function getSetterFor(element: FillableElement) { if (element instanceof HTMLTextAreaElement) { return Object.getOwnPropertyDescriptor( window.HTMLTextAreaElement.prototype, value )!.set } if (element instanceof HTMLSelectElement) { return Object.getOwnPropertyDescriptor( window.HTMLSelectElement.prototype, value )!.set } return Object.getOwnPropertyDescriptor( window.HTMLInputElement.prototype, value )!.set } export function autoFill( element: FillableElement | HTMLElement, value: string ): boolean { try { if (!(element instanceof HTMLElement)) return false if (element.isContentEditable) { element.textContent value element.dispatchEvent(new Event(input, { bubbles: true })) element.dispatchEvent(new Event(change, { bubbles: true })) return true } if ( !(element instanceof HTMLInputElement) !(element instanceof HTMLTextAreaElement) !(element instanceof HTMLSelectElement) ) { return false } const setter getSetterFor(element) // 聚焦目标触发 focus 相关逻辑 element.focus() // 使用原生 setter 赋值 setter.call(element, value) // 更新 React 内部记录避免被“改回” setReactPropValue(element, value) // 派发事件触发 React 合成事件系统 element.dispatchEvent(new Event(input, { bubbles: true })) element.dispatchEvent(new Event(change, { bubbles: true })) // 失焦触发 blur 相关逻辑 element.blur() return true } catch (e) { console.error([autoFill] failed:, element, value, e) return false } }3.3 为什么对这个工具要保留“依次 dispatch input 和 change”很多人会问既然 React 的onChange已经监听input事件了为什么还要补一个change事件理由有两点。第一底层用了某些老旧浏览器行为或某些 web component 封装时input事件的冒泡可能被阻断change往往是兜底。第二某些自定义组件只监听change而不监听input例如部分 React 封装的 Select如果只派发input组件不会刷新。实践下来多派发一个change的副作用几乎为零所以干脆都发。3.4 React 19 下的特殊处理explicitProps与行为差异React 19 在受控组件上有一个比较隐蔽的变化受控和非受控的判定方式做了调整React 会通过props.value是否存在来决定是不是受控组件。同时 React 19 对 input 元素内部value的同步逻辑也更“强硬”。我实测发现在 React 19.1 之前外部赋值后即使更新了__reactProps$某些场景下 React 还是会把值改回去。解决方法是同时更新元素上的__reactProps$...value和__reactProps$...defaultValue并且对于部分自定义组件需要把__reactProps$...onChange手动调用一次function callReactOnChange( element: any, value: string ) { const keys Object.keys(element).filter((key) key.startsWith(__reactProps$) ) for (const key of keys) { const props element[key] if (props typeof props.onChange function) { const eventLike { target: element, currentTarget: element, preventDefault() {}, stopPropagation() {}, nativeEvent: new Event(input, { bubbles: true }), } props.onChange(eventLike) } } }在 React 19.1 版本React 官方在createRoot里增加了一个选项来关闭这种强制回写行为。如果你维护的应用升级到了 React 19.1并且确实需要大量自动化填充可以在入口处这样配createRoot(container, { // 仅当你确实需要外部自动化填充时才建议开启 explicitProps: false, }).render(App /)等等这里很多人会搞反explicitProps: false是让 React 不再对受控属性做“额外保护”。如果你保持默认的true外部通过原生 setter 修改 value 后React 会因为内部记录的严格一致性把值覆盖掉。所以对上文封装的工具函数在 React 19.1 建议与应用侧确认这个配置项。4. 在自动化测试里的正确落地姿势4.1 Testing Library 的 fireEvent 与 userEvent 到底该用哪个如果你只是写前端测试我的建议是能上userEvent就上userEvent。因为userEvent在底层做的事情非常接近真实用户它会在正确的时机触发 focus、keydown、input、keyup、blur 等一系列事件。而fireEvent是一次性触发一个单一事件对 React 的复杂组件来说反而容易“触发不完整”。之前的工具函数更多是给“浏览器插件、动态脚本、跨框架场景”用的在测试环境里你应该优先用 Testing Library 自带的方法import { render, screen } from testing-library/react import userEvent from testing-library/user-event test(fill the form, async () { const user userEvent.setup() render(MyForm /) const input screen.getByLabelText(/用户名/) await user.clear(input) await user.type(input, zhang_san) expect(screen.getByDisplayValue(zhang_san)).toBeInTheDocument() })4.2 React 18/19 下 fireEvent.change 为什么会失效如果你确实只需要触发一次值变更例如把某个输入框直接设为一个固定值fireEvent.change通常是够用的import { fireEvent, render, screen } from testing-library/react const input screen.getByLabelText(/年龄/) fireEvent.change(input, { target: { value: 18 } })但我在 React 18 时代就发现一个现象某些封装过的组件比如antd的Input组件包了一层rc-inputfireEvent.change偶尔会出现“state 没更新”的情况。原因不在于 Testing Library而在于fireEvent.change内部实现是直接调用input元素的 setter它封装了前面的原生 setter 和事件派发但它没有同步 React 内部记录。所以在 React 18 的自定义组件测试里我会在fireEvent.change前手动修正 React 内部属性或者干脆优先用userEvent。用userEvent时它会自己处理这些细节。4.3 遇到“值变了但 state 没变”的测试排查套路我这里整理了一份排查顺序遇到类似问题你按顺序查就行你的 input 是不是真正的受控组件看看代码里有没有value和onChange。你是用的原生input.value xxx还是fireEvent/userEvent原生赋值基本必挂。组件库是否包了一层自定义组件比如rc-input、antd的AutoComplete如果是直接操作最内层的原生input元素。版本是 React 18 还是 19React 19 记得检查explicitProps的默认行为必要时在测试入口配置。有没有演化到blur阶段组件可能在blur里做格式化、转换。4.4 一个 React 19 下的测试示例下面我写一个完整示例在 React 19 下测试一个受控表单组件import { render, screen, fireEvent } from testing-library/react import { useCallback, useState } from react import { describe, expect, it, vi } from vitest function MyForm({ onSubmit }: { onSubmit: (v: string) void }) { const [name, setName] useState() const submit useCallback(() { onSubmit(name) }, [name, onSubmit]) return ( form label 姓名 input value{name} onChange{(e) setName(e.target.value)} / /label button typebutton onClick{submit} 提交 /button /form ) } describe(MyForm, () { it(can fill input and submit, () { const onSubmit vi.fn() render(MyForm onSubmit{onSubmit} /) const input screen.getByLabelText(姓名) // 如果 userEvent 不可用也需要先把 React 内部记录同步 Object.keys(input).forEach((key) { if (key.startsWith(__reactProps$)) { ;(input as any)[key].value hello } }) fireEvent.change(input, { target: { value: hello } }) fireEvent.click(screen.getByText(提交)) expect(onSubmit).toHaveBeenCalledWith(hello) }) })这里多写了一步同步 React 内部记录在 React 19 下能显著提升稳定性。如果你跑测试时发现 state 没变把这段加上大概率能解决。5. 浏览器插件 / 油猴脚本等真实外部环境怎么处理5.1 你面对的是“无 React 环境感知”的页面如果说测试环境里你还能通过 Testing Library 的封装绕过很多坑那么在浏览器插件、油猴脚本、控制台脚本里你就必须完全依赖原生 DOM API 和前面讲的原生 setter 了。这里最核心的难点是你要在正确的时间点用正确的方式把值塞进去并且触发 React 的事件系统。顺序错了、事件类型错了都会静默失败。5.2 实战脚本批量填充一个含多个 React 受控控件的表单假设有个后台页面有一个input#name、一个textarea#desc、一个select#category都是 React 受控组件。脚本可以这样写function fillReactForm(data: Recordstring, string) { const selectors: Recordstring, string { name: input#name, desc: textarea#desc, category: select#category, } for (const [key, selector] of Object.entries(selectors)) { const el document.querySelectorHTMLInputElement | HTMLTextAreaElement | HTMLSelectElement(selector) if (!el) continue const value data[key] if (value null) continue autoFill(el, value) } } // 使用 fillReactForm({ name: 张三, desc: 这是一段自动填入的描述, category: tech, })注意autoFill在这里要使用上一节的封装函数。这段脚本我本人在几个 React 后台项目里跑过覆盖率很高。5.3 一个很容易踩的坑React Fiber 上的事件监听被 React DevTools 覆盖当你打开页面控制台用document.querySelector选到 input 后直接el.dispatchEvent(new Event(input, { bubbles: true }))有时候看到 React 开发者工具里 state 变了但页面上绑定的业务回调没执行。这是因为 React 的合成事件系统除了依赖原生事件冒泡还依赖Event对象的target和currentTarget。某些封装组件内部使用了event.currentTarget而我们手动 new 出来的事件在部分浏览器里currentTarget为 null导致 React 内部onChange拿不到目标。解决方式自己构造一个更完整的“事件对象”再调用__reactProps$...onChange。这个在上面的callReactOnChange里已经做了这也是为什么在某些极端情况下直接调用props.onChange会比dispatchEvent更可靠。6. 常见问题与排查技巧实录6.1 问题速查表我把实际工作中最常遇到的几种情况整理成一张表方便你对照排查现象原因解决方案input.value xxx后页面显示了但一输入字符就变回去React 内部对账机制覆盖外部赋值使用原生 value setter并派发input事件dispatchinput事件了React state 还是旧值React 18/19 内部记录了之前的 value认为外部赋值不合法同步更新__reactProps$...value在 React 19 里所有方法都试了还是被改回React 19 的explicitProps默认开启严格受控在createRoot里配置explicitProps: false或调用props.onChange在antd组件里填值后校验不通过组件可能在blur时做格式化补上focus、blur步骤事件触发了但onChange拿到的值被截断组件内部有maxLength或过滤逻辑检查最内层 input确认是否存在自定义输入过滤在测试里fireEvent.change失效测试环境 React 版本或组件封装层级问题改用userEvent或先同步 React 内部记录6.2 独家避坑别在微任务里重置值还有一个很容易被忽视的坑如果你在dispatchEvent(new Event(input))之后的微任务里立刻把input.value重置成空字符串React 的批量更新可能会把这次赋值也算进去导致最终 state 是空值。我用Promise.resolve()包裹后续操作时踩过一次后面改成setTimeout(..., 0)或者直接同步完成问题消失。6.3 另一种思路非受控组件场景下反而简单如果你有权限改代码建议在需要频繁做外部填充的场景里考虑把受控组件改成非受控组件即不传value只传defaultValue然后通过ref去读取值。这样外部脚本直接input.value xxx就不会被 React 改回去问题从根上消失。但要注意非受控组件在需要联动、校验、动态重置的场景下会很别扭。所以我的建议是自动化填充需求只出现在测试里时老老实实用受控组件 正确的事件派发如果是对外提供脚本接口的产品化功能再考虑非受控 ref 的方案。7. 实操中的最后几点体会这些方法我在多个 React 项目里反复验证过各自踩过的坑远比文章里写的多。一开始我也迷信fireEvent.change一劳永逸直到在 React 18 升级时被线上问题打脸才老老实实把原生 setter、事件派发、__reactProps$更新这套组合逻辑补齐。现在遇到任何“受控组件填不进去”的问题我的排查时间是按分钟来算的。最后分享一个小技巧在写浏览器脚本时可以在控制台临时跑一段代码把某个 input 元素的__reactProps$对象里的onChange打印出来看看它到底是个什么函数。这一步能帮你快速判断这个组件是原生受控组件还是经过第三方库封装的自定义组件从而决定该用哪种填充策略。这个方法比反复看源码高效得多你试一次就知道。
 替代 sort() 避免 React 状态原地变异 bug)
