上周帮一位做运营的朋友处理一批商品数据他要在后台系统里一次性录入两百多条记录每条都要点开弹窗填十几个字段。他写了个脚本用document.querySelector拿到输入框el.value xxx一把梭页面上确实看到字填进去了兴冲冲点了保存结果提交出去的接口参数里全是空字符串。他把截图发过来说字明明都在框里了为什么提交的是空。问题就出在这儿——你看到的是 DOMVue 看到的是数据。在v-model这套机制下两边是单向同步的数据变了会写进 DOM但 DOM 里的值变了不会自动回写数据除非这个改动是通过事件这条路走进来的。这篇就把这条路彻底走一遍从v-model编译后长什么样到原生事件怎么派发再到组件库封装层怎么绕过去最后给一套可以直接抄的封装写法。适合正在写自动化脚本、浏览器扩展、测试用例或者维护着Vue 里混着老 jQuery 代码这类项目的人看。哪怕你只会写最简单的 DOM 操作跟着走一遍也能自己排查。1. 直接改 value 之后页面没反应问题到底卡在哪1.1 一个典型现象输入框有字提交却是空先把现象拆开。当你在控制台执行document.querySelector(input).value 测试页面上输入框确实出现了测试两个字这一步是浏览器原生行为跟框架一点关系都没有。但只要你打开开发者工具的 Vue 面板看一眼绑定的那个form.xxx还是空的。原因很直白el.value x只是修改了 DOM 节点上的一个属性。Vue 的响应式数据和 DOM 之间没有双向监听这回事——它只在数据变化时把值写下去从来不去轮询 DOM 看值有没有被改。真正让数据变的那条通道是input事件。你绕过事件直接改 DOM相当于从后门溜进去做了个样子货Vue 的数据层完全不知道发生了什么。所以正确的思路不是怎么让 Vue 发现 DOM 变了而是怎么装成用户输入的样子把这件事正常走一遍流程。这句话是整篇文章的核心后面所有的技巧都是围绕它展开的。1.2 Vue 并不监听 DOM 的 value它监听的是事件很多人第一次遇到这个问题会下意识去搜Vue 监听 input value 变化然后找到一堆watch的用法越看越糊涂。方向从一开始就错了。Vue 的v-model本质上做了两件事把数据渲染到元素的value上以及在元素上挂一个input事件监听器事件里把event.target.value赋回数据。就这两件事。这也解释了为什么手动派发一个 input 事件能奏效那个监听器一直都在只是没有被触发过。你派发事件等于替用户按了一下键盘监听器照常执行数据照常更新后续的校验、联动、格式化全都跟着一起跑起来了。这是最干净、副作用最小的做法也是后面所有方案里优先级最高的那个。反过来说那些直接摸到 Vue 实例改 data的做法虽然也能生效但它跳过了事件链路凡是挂在input或者change上的业务逻辑比如自动计算总价、实时搜索、联动下拉全都不会触发。这个区别在实际项目里非常关键后面第 4 节会详细说。2. v-model 编译后到底是什么Vue2 与 Vue3 的绑定链路拆解2.1 Vue2 的 v-model 是 value input 的语法糖在 Vue2 里写在原生 input 上的v-modelform.name编译出来大致是这样一段渲染逻辑{ value: form.name, input: function ($event) { form.name $event.target.value } }也就是说它被展开成了:value加input。Vue2 在 patch 阶段通过updateDOMListeners把input监听器用addEventListener真正挂到元素上同时把value作为 DOM 属性写进去。注意这里两个动作是分开的写 value 是渲染挂监听是绑定互不干扰。理解了这一点你就明白为什么改 value 不生效——你只做了渲染那一半监听那一半没被触发。Vue2 在后续任何一次重渲染时还会拿数据里的旧值把el.value覆盖回去所以你手动塞进去的字可能过一会儿就自己消失了。这个现象在列表滚动、分页切换、弹窗重开的时候特别容易出现很多人以为是自己代码写错了其实是被重渲染冲掉了。2.2 Vue3 里 v-model 换成了 modelValue update:modelValueVue3 在组件上把v-model改成了modelValue属性加update:modelValue事件。但在原生元素上它走的是另一条路——编译成一个运行时指令vModelText而不是简单的属性加监听。这个指令在created钩子里自己做addEventListener在beforeUpdate里做值比较和写入。这个差异带来一个很实际的影响。Vue3 的vModelText在beforeUpdate里有这么一段判断逻辑如果当前元素是焦点元素并且类型不是 range那么在lazy、trim、number这几种修饰符命中的情况下会跳过 DOM 写入。也就是说在你聚焦着这个输入框的时候手动改的 value 不会被立刻覆盖回去看起来成功了但只要你点一下别处让它失焦下一次重渲染立刻把值打回原形。这就是很多人说的填完看着是对的一提交就空的真实成因。我把两代的关键差异整理成一张表方便对照对比维度Vue2Vue3原生元素上的实现编译成value属性 input监听函数编译成vModelText运行时指令组件上的语法糖valueinput事件modelValueupdate:modelValue事件监听注册位置patch 阶段updateDOMListeners指令created钩子内DOM 回写时机每次 patch 直接赋值beforeUpdate中比较后再赋值焦点状态下外部改值会被重渲染覆盖部分修饰符场景下跳过覆盖调试用的实例引用元素上的__vue__元素上的__vueParentComponent2.3 响应式系统只认它自己收到的那次赋值不管是 Vue2 的Object.defineProperty还是 Vue3 的Proxy拦截的都是对数据的读写这个动作。你从控制台改el.value压根没经过数据对象拦截器自然什么都不知道。这里有个很常见的误解有人觉得Vue3 用 Proxy 了是不是能监听 DOM 变化。不能。Proxy 代理的是 JS 对象DOM 元素不是普通 JS 对象它的属性访问走的是浏览器内部的 C 实现跟 Proxy 没关系。所以不管哪一代结论都一样——必须走事件。还有个小细节值得记住Vue 的响应式更新是异步批处理的派发事件之后数据不是立刻变的要等下一个微任务队列 flush。所以在脚本里派发完事件马上去读vm.form.name很可能还是旧值。要读的话套一个await nextTick()或者await new Promise(r setTimeout(r, 0))。这个坑我在写自动化脚本时踩过不止一次明明事件派发成功了断言却一直失败。3. 事件派发的完整写法input、change 与只读字段3.1 最小可用代码与逐行解释最核心的代码其实只有三行const input document.querySelector(#username) input.value 张三 input.dispatchEvent(new Event(input, { bubbles: true }))第一行拿到元素第二行写值第三行派发事件。关键在bubbles: true这个参数——事件必须能冒泡因为 Vue 的监听器有时候不是挂在元素本身而是挂在父级的容器上尤其是列表渲染的场景。不冒泡的事件只在当前元素上触发父级的监听器根本收不到。如果要更稳妥一点我会用原型上的 setter 来写值而不是直接赋值function setNativeValue(el, value) { const proto el instanceof HTMLTextAreaElement ? HTMLTextAreaElement.prototype : HTMLInputElement.prototype const setter Object.getOwnPropertyDescriptor(proto, value).set setter.call(el, value) }多这几行的意义在于某些框架或者第三方库会在元素实例上重定义value的 getter/setter用来做内部状态追踪React 就是典型代表它的受控组件必须这么绕。虽然纯 Vue 项目用不上但自动化脚本往往是通用工具要跑在各种各样的页面上用原型 setter 基本不会出错成本也就多了两行。3.2 为什么有时候还得补一个 changeinput事件在每次值变化时都会触发change事件则是值确定后失焦或回车才触发。绝大多数v-model用的是input所以派发input就够了。但如果你看到模板上写的是v-model.lazyform.xxx那就得派发change。.lazy修饰符的作用就是把监听从input换成change这时候你派发input是白费的。判断方法很简单在开发者工具的 Vue 面板里看这个绑定的修饰符或者直接搜代码里有没有.lazy。稳妥的做法是两个都派el.dispatchEvent(new Event(input, { bubbles: true })) el.dispatchEvent(new Event(change, { bubbles: true }))成本几乎为零幂等性也没问题——Vue 那边同一个值赋两次不会出乱子因为写入前会做相等比较。唯一的副作用是如果业务代码在input和change里都做了请求或者统计可能会重复触发一次。所以我能确定是哪个就用哪个不确定才两个都来。3.3 composition 事件与输入法的隐形拦截Vue3 的vModelText指令在处理输入时会检查一个内部标记。它在compositionstart时给元素打上el.composing true在compositionend时清掉并补发一次input。事件处理函数里第一句就是if (e.target.composing) return。这意味着如果目标元素上残留着composing为真比如用户正在用输入法打字时被脚本打断或者某些输入法组件没有正常派发compositionend你派发的所有input事件都会被静默丢弃。这种 bug 极其难查因为控制台里事件明明发出去了代码里却一点反应没有。排查办法就是在派发前手动检查并清理if (el.composing) { el.composing false } el.dispatchEvent(new Event(input, { bubbles: true }))更完整的做法是在赋值前主动派发一对 composition 事件模拟一次完整的输入过程el.dispatchEvent(new CompositionEvent(compositionstart, { bubbles: true })) setNativeValue(el, value) el.dispatchEvent(new CompositionEvent(compositionend, { bubbles: true }))但说实话这套只在处理中文、日文这类需要输入法组字的场景才有意义普通英文数字填充用不上反而可能因为模拟得不够真实引入新问题。我的习惯是先不派出问题再派。提示派发compositionend之后Vue3 的指令会自己再补一次input事件所以不要再额外派一次否则业务逻辑会跑两遍。3.4 修饰符带来的额外处理.trim和.number这两个修饰符会让 Vue 在事件回调里对值做二次加工。.trim会去掉首尾空格.number会尝试转成数字。这两个行为都是在你派发事件之后由 Vue 内部完成的脚本这边不用管。但有个例外如果目标是typenumber的输入框而你要填的值不是合法数字比如空字符串或者带单位的字符串浏览器会拒绝写入el.value读出来是空。这种情况在自动化脚本里很常见尤其是某些后台系统的金额字段加了千分位显示。解决办法是先设成typetext再填或者干脆改走组件实例的路子下一节讲。这种时候别硬刚浏览器换个思路更快。4. 顺着 DOM 摸到组件实例两条直接改数据的路子4.1 事件派发搞不定的场景长什么样原生事件方案覆盖了 80% 的情况但有几类场景它确实无能为力一是非文本控件比如日期选择器、级联选择、下拉框它们的显示值不是通过input的 value 呈现的二是组件内部对输入做了强烈干预比如只允许输入中文、自动格式化手机号、限制最大长度你派发完事件值被清洗掉了三是元素本身是readonly或者disabled原生事件根本进不去。这时候就得换一条路——直接摸到 Vue 的组件实例改它内部的数据。这条路在原理上更暴力但也更通用。4.2 找到实例vue与 __vueParentComponentVue2 会在组件根元素上挂一个__vue__属性Vue3 则是在元素上挂__vueParentComponentVue 3.2 之后的名字。两者的共同点是只在开发构建里稳定存在生产构建里通常没有。这一点必须先说清楚否则你在本地调试得好好的脚本一上线就全废。写个通用的向上查找函数function findVueInstance(el) { let node el while (node) { if (node.__vueParentComponent) { return { version: 3, instance: node.__vueParentComponent } } if (node.__vue__) { return { version: 2, instance: node.__vue__ } } node node.parentElement } return null }为什么是向上遍历因为__vueParentComponent挂在元素所在的组件实例上输入框本身如果只是组件内部的普通元素它自己身上是有的但也有挂载在祖先节点的情况。往上找几层基本能命中。拿到实例之后怎么用两代差别不小// Vue2触发组件的 v-model const vm el.__vue__ vm.$emit(input, 新值) // Vue3触发组件的 v-model const inst el.__vueParentComponent inst.ctx.$emit(update:modelValue, 新值)ctx.$emit在 Vue3 里是能拿到的它等价于组件内部的emit。不过更稳的写法是通过exposed或者直接改setupStateconst inst el.__vueParentComponent inst.setupState.form.name 新值setupState是被proxyRefs包裹过的如果你在script setup里写的是const name ref()那么inst.setupState.name x会自动写到.value上不用手动加.value。这个特性很省事但也容易让人误以为可以直接改ref。对于reactive定义的 form 对象改它的属性同样会触发更新。4.3 直接改实例数据的适用边界这条路快、准、狠但代价是——所有靠事件驱动的逻辑全部失效。举个我遇到过的例子某个表单里填写数量之后要联动计算总价这个逻辑挂在input上。我用实例改数据数量变了总价纹丝不动提交上去的金额是错的。后来改成先改数据、再手动派发一次事件才把这个联动带上。所以我的实际用法是组合拳优先原生事件派发不奏效的时候改用实例赋值赋完值之后再补派一次原生事件让监听链路跑一遍。这样数据和联动都能兼顾。顺序不能反先派事件后改值事件里读到的还是旧值等于白派。还有一点必须提醒setupState只在开发构建里能完整拿到生产环境经过压缩后属性名全变了这套写法基本没法用。如果你的脚本是要长期跑在别人家的系统上老老实实用原生事件方案别指望实例引用。5. 组件库的坑受控输入框、自定义 v-model 与多层透传5.1 封装组件里的那一层薄薄的壳主流组件库的输入框本质都是内部一个原生 input 外面包一层壳。比如 Element 系列的输入框最终渲染出来的还是一个input元素v-model绑在组件上组件内部再把modelValue透传给内部的原生 input。大部分情况下对内部那个原生 input 派发input事件事件会冒泡到组件内部的处理函数进而触发update:modelValue整个链路是通的。所以第 3 节的方案在组件库场景下照样能用不用一上来就去找实例。但有几个坑要提前知道。第一个是只读输入框有些组件的输入框带了readonly或者unselectable目的是让用户只能通过弹层选择而不能直接输入。这类元素派发事件是没用的因为组件内部的处理函数会判断来源。第二个是带前缀后缀的输入框DOM 结构里可能有好几个 inputquerySelector(input)拿到的未必是你要的那个得用更精确的选择器或者:not([readonly])过滤。我一般的判断顺序是先看 DOM 里有没有原生 input 且不是 readonly有就走事件没有再考虑实例。5.2 日期、下拉、级联这些非文本控件这类控件是最麻烦的。它们表面上看起来有个输入框实际上那个框可能只是个展示用的 div 或者 readonly input真正的值存在组件内部的modelValue上。对这类控件事件派发基本无效只能走实例function setComponentValue(el, value) { const node findVueInstance(el) if (!node) return false const { version, instance } node if (version 3) { instance.ctx?.$emit?.(update:modelValue, value) return true } instance.$emit?.(input, value) return true }注意 Vue3 这里用的是update:modelValue如果组件的v-model带了参数名比如v-model:visible事件名就是update:visible得对应改。判断方法是在 Vue 面板里看组件的 props 名。还有一类更隐蔽的情况组件外面套了v-model但内部又做了一层格式化。比如日期组件要求传入的是Date对象或者特定格式的字符串你传个2024-01-01上去组件内部dayjs解析失败值变成空。这类问题只能靠试——先试字符串不行试时间戳再不行试Date对象。我遇到过某组件只认 ISO 格式带T的字符串折腾了半小时才试出来。5.3 表单校验与脏值判断填完值之后很多表单还有一步点提交时统一校验字段没变过就跳过。Vue 的校验库比如基于 async-validator 的那套通常是通过trigger: change或trigger: blur来触发字段校验的。如果你只派发了input校验不会跑提交时还是会报请填写xxx。解决办法是补派change和blurel.dispatchEvent(new Event(input, { bubbles: true })) el.dispatchEvent(new Event(change, { bubbles: true })) el.dispatchEvent(new Event(blur, { bubbles: true }))blur事件要注意它本身不冒泡但 Vue 里通过blur绑定时是通过addEventListener挂在元素上的所以不冒泡也能触发。不过如果你要派发给父级得用new FocusEvent(blur, { bubbles: false })这个细节别搞混。还有一个常被忽略的点某些表单会记录初始值快照提交时对比当前值和快照一样就不提交这个字段。这种情况你怎么填都没用因为它的判断逻辑压根不看 DOM。这种时候唯一的办法是走实例改数据让快照对比失效。这也是为什么我总说自动化脚本这东西能通一百个页面第一百零一个总能给你惊喜。6. 完整排查链路与工程化封装6.1 从值变了到数据没变的四步定位遇到填不进去的情况别急着改代码按这个顺序往下走基本能在几分钟内定位到具体环节。第一步确认数据到底变没变。打开开发者工具找到目标元素在控制台里$0.__vue__或者$0.__vueParentComponent看看绑定的数据当前是什么值。如果数据已经变了但界面没变那问题在渲染层如果数据没变继续往下。第二步确认事件有没有被监听到。在元素上手动加一个临时监听器$0.addEventListener(input, e console.log(收到, e.target.value))然后派发一次事件看控制台有没有输出。没输出说明事件根本没到元素上检查是不是被别的层挡住了或者元素选错了。第三步确认事件有没有被吞。检查元素的readonly、disabled状态检查el.composing标记检查是不是层级选错了拿到了外层容器而不是真正的输入框。这一步用console.log(el.tagName, el.type, el.readOnly, el.disabled)一次性打完。第四步确认值有没有被二次覆盖。派发事件之后等 100 毫秒再看数据如果变了又变回去说明有个 watcher 在监听并做了格式化或者纠正。这种情况得去看数据层的逻辑光在 DOM 层面折腾是解决不了的。这四步走下来我遇到过的九成问题都能定位。剩下那一成通常是页面用了 iframe 或者 Shadow DOM元素根本不在主文档里document.querySelector天然拿不到。这种得先穿透进去属于另一个话题了。6.2 封装一个能扛事的填充函数把上面所有要点收拢我平时用的工具函数大概是这样function fillInput(el, value, options {}) { const { triggerChange true, triggerBlur false } options if (!el) throw new Error(目标元素不存在) // 清理可能残留的输入法标记 if (el.composing) el.composing false // 用原型 setter 写值兼容混合框架场景 const proto el instanceof HTMLTextAreaElement ? HTMLTextAreaElement.prototype : HTMLInputElement.prototype const setter Object.getOwnPropertyDescriptor(proto, value).set setter.call(el, value) el.dispatchEvent(new Event(input, { bubbles: true })) if (triggerChange) { el.dispatchEvent(new Event(change, { bubbles: true })) } if (triggerBlur) { el.dispatchEvent(new FocusEvent(blur, { bubbles: false })) } return el.value String(value) }返回值这里值得说一下。我用el.value String(value)做一次校验是因为有些输入框会对值做格式化比如手机号自动加空格、金额自动加千分位写进去的值和你期望的可能对不上。返回false的时候你就知道要额外处理了比默默失败强得多。再配一个批量填充的版本async function fillForm(map, { delay 50 } {}) { const results [] for (const [selector, value] of Object.entries(map)) { const el document.querySelector(selector) try { const ok fillInput(el, value) results.push({ selector, ok }) } catch (err) { results.push({ selector, ok: false, error: err.message }) } // 给 Vue 的异步更新留出时间 await new Promise(resolve setTimeout(resolve, delay)) } return results }那个delay不是随便加的。Vue 的更新是批处理的连续快速填充多个字段时如果某个字段的输入会触发联动计算比如填了省份自动带出城市列表下一个字段的 DOM 可能还没渲染出来querySelector就会返回null。给个 30 到 80 毫秒的间隔实测下来能解决绝大部分时序问题。宁可慢一点也别在后面加一堆重试逻辑。6.3 异步等待与重试的正确姿势严格来说靠setTimeout等 DOM 是个不太优雅的做法但它在自动化脚本里是性价比最高的。更稳的方式是用MutationObserver监听 DOM 变化等目标元素出现再操作function waitFor(selector, timeout 3000) { return new Promise((resolve, reject) { const found document.querySelector(selector) if (found) return resolve(found) const observer new MutationObserver(() { const el document.querySelector(selector) if (el) { observer.disconnect() resolve(el) } }) observer.observe(document.body, { childList: true, subtree: true }) setTimeout(() { observer.disconnect() reject(new Error(等待 ${selector} 超时)) }, timeout) }) }这个函数在弹窗场景下特别有用。很多后台系统的表单是弹窗形式点新增之后要等动画播完、组件挂载完成输入框才真正存在于 DOM 里。用固定延时等待机器快了慢了都不准用 MutationObserver 则是一出现就动手既快又稳。我个人的习惯是两者结合先用waitFor等元素出现填完之后用短延时等联动生效。只用其中一种在某些页面上总会翻车。最后分享一个我自己踩出来的经验写这类自动化脚本千万别在控制台里反复手敲调试。页面刷新一次就得重来一遍效率极低。正确做法是把逻辑写成一个函数存在书签脚本或者浏览器扩展里刷新后一键执行每次改一行就在函数里改验证一次到位。这比在控制台里堆几十行临时命令高效太多也更容易发现那些只在特定数据下才暴露的边界问题——比如填了空字符串、填了超长文本、填了负数这三种情况几乎每个表单都会出点岔子。
上周帮一位做运营的朋友处理一批商品数据他要在后台系统里一次性录入两百多条记录每条都要点开弹窗填十几个字段。他写了个脚本用document.querySelector拿到输入框el.value xxx一把梭页面上确实看到字填进去了兴冲冲点了保存结果提交出去的接口参数里全是空字符串。他把截图发过来说字明明都在框里了为什么提交的是空。问题就出在这儿——你看到的是 DOMVue 看到的是数据。在v-model这套机制下两边是单向同步的数据变了会写进 DOM但 DOM 里的值变了不会自动回写数据除非这个改动是通过事件这条路走进来的。这篇就把这条路彻底走一遍从v-model编译后长什么样到原生事件怎么派发再到组件库封装层怎么绕过去最后给一套可以直接抄的封装写法。适合正在写自动化脚本、浏览器扩展、测试用例或者维护着Vue 里混着老 jQuery 代码这类项目的人看。哪怕你只会写最简单的 DOM 操作跟着走一遍也能自己排查。1. 直接改 value 之后页面没反应问题到底卡在哪1.1 一个典型现象输入框有字提交却是空先把现象拆开。当你在控制台执行document.querySelector(input).value 测试页面上输入框确实出现了测试两个字这一步是浏览器原生行为跟框架一点关系都没有。但只要你打开开发者工具的 Vue 面板看一眼绑定的那个form.xxx还是空的。原因很直白el.value x只是修改了 DOM 节点上的一个属性。Vue 的响应式数据和 DOM 之间没有双向监听这回事——它只在数据变化时把值写下去从来不去轮询 DOM 看值有没有被改。真正让数据变的那条通道是input事件。你绕过事件直接改 DOM相当于从后门溜进去做了个样子货Vue 的数据层完全不知道发生了什么。所以正确的思路不是怎么让 Vue 发现 DOM 变了而是怎么装成用户输入的样子把这件事正常走一遍流程。这句话是整篇文章的核心后面所有的技巧都是围绕它展开的。1.2 Vue 并不监听 DOM 的 value它监听的是事件很多人第一次遇到这个问题会下意识去搜Vue 监听 input value 变化然后找到一堆watch的用法越看越糊涂。方向从一开始就错了。Vue 的v-model本质上做了两件事把数据渲染到元素的value上以及在元素上挂一个input事件监听器事件里把event.target.value赋回数据。就这两件事。这也解释了为什么手动派发一个 input 事件能奏效那个监听器一直都在只是没有被触发过。你派发事件等于替用户按了一下键盘监听器照常执行数据照常更新后续的校验、联动、格式化全都跟着一起跑起来了。这是最干净、副作用最小的做法也是后面所有方案里优先级最高的那个。反过来说那些直接摸到 Vue 实例改 data的做法虽然也能生效但它跳过了事件链路凡是挂在input或者change上的业务逻辑比如自动计算总价、实时搜索、联动下拉全都不会触发。这个区别在实际项目里非常关键后面第 4 节会详细说。2. v-model 编译后到底是什么Vue2 与 Vue3 的绑定链路拆解2.1 Vue2 的 v-model 是 value input 的语法糖在 Vue2 里写在原生 input 上的v-modelform.name编译出来大致是这样一段渲染逻辑{ value: form.name, input: function ($event) { form.name $event.target.value } }也就是说它被展开成了:value加input。Vue2 在 patch 阶段通过updateDOMListeners把input监听器用addEventListener真正挂到元素上同时把value作为 DOM 属性写进去。注意这里两个动作是分开的写 value 是渲染挂监听是绑定互不干扰。理解了这一点你就明白为什么改 value 不生效——你只做了渲染那一半监听那一半没被触发。Vue2 在后续任何一次重渲染时还会拿数据里的旧值把el.value覆盖回去所以你手动塞进去的字可能过一会儿就自己消失了。这个现象在列表滚动、分页切换、弹窗重开的时候特别容易出现很多人以为是自己代码写错了其实是被重渲染冲掉了。2.2 Vue3 里 v-model 换成了 modelValue update:modelValueVue3 在组件上把v-model改成了modelValue属性加update:modelValue事件。但在原生元素上它走的是另一条路——编译成一个运行时指令vModelText而不是简单的属性加监听。这个指令在created钩子里自己做addEventListener在beforeUpdate里做值比较和写入。这个差异带来一个很实际的影响。Vue3 的vModelText在beforeUpdate里有这么一段判断逻辑如果当前元素是焦点元素并且类型不是 range那么在lazy、trim、number这几种修饰符命中的情况下会跳过 DOM 写入。也就是说在你聚焦着这个输入框的时候手动改的 value 不会被立刻覆盖回去看起来成功了但只要你点一下别处让它失焦下一次重渲染立刻把值打回原形。这就是很多人说的填完看着是对的一提交就空的真实成因。我把两代的关键差异整理成一张表方便对照对比维度Vue2Vue3原生元素上的实现编译成value属性 input监听函数编译成vModelText运行时指令组件上的语法糖valueinput事件modelValueupdate:modelValue事件监听注册位置patch 阶段updateDOMListeners指令created钩子内DOM 回写时机每次 patch 直接赋值beforeUpdate中比较后再赋值焦点状态下外部改值会被重渲染覆盖部分修饰符场景下跳过覆盖调试用的实例引用元素上的__vue__元素上的__vueParentComponent2.3 响应式系统只认它自己收到的那次赋值不管是 Vue2 的Object.defineProperty还是 Vue3 的Proxy拦截的都是对数据的读写这个动作。你从控制台改el.value压根没经过数据对象拦截器自然什么都不知道。这里有个很常见的误解有人觉得Vue3 用 Proxy 了是不是能监听 DOM 变化。不能。Proxy 代理的是 JS 对象DOM 元素不是普通 JS 对象它的属性访问走的是浏览器内部的 C 实现跟 Proxy 没关系。所以不管哪一代结论都一样——必须走事件。还有个小细节值得记住Vue 的响应式更新是异步批处理的派发事件之后数据不是立刻变的要等下一个微任务队列 flush。所以在脚本里派发完事件马上去读vm.form.name很可能还是旧值。要读的话套一个await nextTick()或者await new Promise(r setTimeout(r, 0))。这个坑我在写自动化脚本时踩过不止一次明明事件派发成功了断言却一直失败。3. 事件派发的完整写法input、change 与只读字段3.1 最小可用代码与逐行解释最核心的代码其实只有三行const input document.querySelector(#username) input.value 张三 input.dispatchEvent(new Event(input, { bubbles: true }))第一行拿到元素第二行写值第三行派发事件。关键在bubbles: true这个参数——事件必须能冒泡因为 Vue 的监听器有时候不是挂在元素本身而是挂在父级的容器上尤其是列表渲染的场景。不冒泡的事件只在当前元素上触发父级的监听器根本收不到。如果要更稳妥一点我会用原型上的 setter 来写值而不是直接赋值function setNativeValue(el, value) { const proto el instanceof HTMLTextAreaElement ? HTMLTextAreaElement.prototype : HTMLInputElement.prototype const setter Object.getOwnPropertyDescriptor(proto, value).set setter.call(el, value) }多这几行的意义在于某些框架或者第三方库会在元素实例上重定义value的 getter/setter用来做内部状态追踪React 就是典型代表它的受控组件必须这么绕。虽然纯 Vue 项目用不上但自动化脚本往往是通用工具要跑在各种各样的页面上用原型 setter 基本不会出错成本也就多了两行。3.2 为什么有时候还得补一个 changeinput事件在每次值变化时都会触发change事件则是值确定后失焦或回车才触发。绝大多数v-model用的是input所以派发input就够了。但如果你看到模板上写的是v-model.lazyform.xxx那就得派发change。.lazy修饰符的作用就是把监听从input换成change这时候你派发input是白费的。判断方法很简单在开发者工具的 Vue 面板里看这个绑定的修饰符或者直接搜代码里有没有.lazy。稳妥的做法是两个都派el.dispatchEvent(new Event(input, { bubbles: true })) el.dispatchEvent(new Event(change, { bubbles: true }))成本几乎为零幂等性也没问题——Vue 那边同一个值赋两次不会出乱子因为写入前会做相等比较。唯一的副作用是如果业务代码在input和change里都做了请求或者统计可能会重复触发一次。所以我能确定是哪个就用哪个不确定才两个都来。3.3 composition 事件与输入法的隐形拦截Vue3 的vModelText指令在处理输入时会检查一个内部标记。它在compositionstart时给元素打上el.composing true在compositionend时清掉并补发一次input。事件处理函数里第一句就是if (e.target.composing) return。这意味着如果目标元素上残留着composing为真比如用户正在用输入法打字时被脚本打断或者某些输入法组件没有正常派发compositionend你派发的所有input事件都会被静默丢弃。这种 bug 极其难查因为控制台里事件明明发出去了代码里却一点反应没有。排查办法就是在派发前手动检查并清理if (el.composing) { el.composing false } el.dispatchEvent(new Event(input, { bubbles: true }))更完整的做法是在赋值前主动派发一对 composition 事件模拟一次完整的输入过程el.dispatchEvent(new CompositionEvent(compositionstart, { bubbles: true })) setNativeValue(el, value) el.dispatchEvent(new CompositionEvent(compositionend, { bubbles: true }))但说实话这套只在处理中文、日文这类需要输入法组字的场景才有意义普通英文数字填充用不上反而可能因为模拟得不够真实引入新问题。我的习惯是先不派出问题再派。提示派发compositionend之后Vue3 的指令会自己再补一次input事件所以不要再额外派一次否则业务逻辑会跑两遍。3.4 修饰符带来的额外处理.trim和.number这两个修饰符会让 Vue 在事件回调里对值做二次加工。.trim会去掉首尾空格.number会尝试转成数字。这两个行为都是在你派发事件之后由 Vue 内部完成的脚本这边不用管。但有个例外如果目标是typenumber的输入框而你要填的值不是合法数字比如空字符串或者带单位的字符串浏览器会拒绝写入el.value读出来是空。这种情况在自动化脚本里很常见尤其是某些后台系统的金额字段加了千分位显示。解决办法是先设成typetext再填或者干脆改走组件实例的路子下一节讲。这种时候别硬刚浏览器换个思路更快。4. 顺着 DOM 摸到组件实例两条直接改数据的路子4.1 事件派发搞不定的场景长什么样原生事件方案覆盖了 80% 的情况但有几类场景它确实无能为力一是非文本控件比如日期选择器、级联选择、下拉框它们的显示值不是通过input的 value 呈现的二是组件内部对输入做了强烈干预比如只允许输入中文、自动格式化手机号、限制最大长度你派发完事件值被清洗掉了三是元素本身是readonly或者disabled原生事件根本进不去。这时候就得换一条路——直接摸到 Vue 的组件实例改它内部的数据。这条路在原理上更暴力但也更通用。4.2 找到实例vue与 __vueParentComponentVue2 会在组件根元素上挂一个__vue__属性Vue3 则是在元素上挂__vueParentComponentVue 3.2 之后的名字。两者的共同点是只在开发构建里稳定存在生产构建里通常没有。这一点必须先说清楚否则你在本地调试得好好的脚本一上线就全废。写个通用的向上查找函数function findVueInstance(el) { let node el while (node) { if (node.__vueParentComponent) { return { version: 3, instance: node.__vueParentComponent } } if (node.__vue__) { return { version: 2, instance: node.__vue__ } } node node.parentElement } return null }为什么是向上遍历因为__vueParentComponent挂在元素所在的组件实例上输入框本身如果只是组件内部的普通元素它自己身上是有的但也有挂载在祖先节点的情况。往上找几层基本能命中。拿到实例之后怎么用两代差别不小// Vue2触发组件的 v-model const vm el.__vue__ vm.$emit(input, 新值) // Vue3触发组件的 v-model const inst el.__vueParentComponent inst.ctx.$emit(update:modelValue, 新值)ctx.$emit在 Vue3 里是能拿到的它等价于组件内部的emit。不过更稳的写法是通过exposed或者直接改setupStateconst inst el.__vueParentComponent inst.setupState.form.name 新值setupState是被proxyRefs包裹过的如果你在script setup里写的是const name ref()那么inst.setupState.name x会自动写到.value上不用手动加.value。这个特性很省事但也容易让人误以为可以直接改ref。对于reactive定义的 form 对象改它的属性同样会触发更新。4.3 直接改实例数据的适用边界这条路快、准、狠但代价是——所有靠事件驱动的逻辑全部失效。举个我遇到过的例子某个表单里填写数量之后要联动计算总价这个逻辑挂在input上。我用实例改数据数量变了总价纹丝不动提交上去的金额是错的。后来改成先改数据、再手动派发一次事件才把这个联动带上。所以我的实际用法是组合拳优先原生事件派发不奏效的时候改用实例赋值赋完值之后再补派一次原生事件让监听链路跑一遍。这样数据和联动都能兼顾。顺序不能反先派事件后改值事件里读到的还是旧值等于白派。还有一点必须提醒setupState只在开发构建里能完整拿到生产环境经过压缩后属性名全变了这套写法基本没法用。如果你的脚本是要长期跑在别人家的系统上老老实实用原生事件方案别指望实例引用。5. 组件库的坑受控输入框、自定义 v-model 与多层透传5.1 封装组件里的那一层薄薄的壳主流组件库的输入框本质都是内部一个原生 input 外面包一层壳。比如 Element 系列的输入框最终渲染出来的还是一个input元素v-model绑在组件上组件内部再把modelValue透传给内部的原生 input。大部分情况下对内部那个原生 input 派发input事件事件会冒泡到组件内部的处理函数进而触发update:modelValue整个链路是通的。所以第 3 节的方案在组件库场景下照样能用不用一上来就去找实例。但有几个坑要提前知道。第一个是只读输入框有些组件的输入框带了readonly或者unselectable目的是让用户只能通过弹层选择而不能直接输入。这类元素派发事件是没用的因为组件内部的处理函数会判断来源。第二个是带前缀后缀的输入框DOM 结构里可能有好几个 inputquerySelector(input)拿到的未必是你要的那个得用更精确的选择器或者:not([readonly])过滤。我一般的判断顺序是先看 DOM 里有没有原生 input 且不是 readonly有就走事件没有再考虑实例。5.2 日期、下拉、级联这些非文本控件这类控件是最麻烦的。它们表面上看起来有个输入框实际上那个框可能只是个展示用的 div 或者 readonly input真正的值存在组件内部的modelValue上。对这类控件事件派发基本无效只能走实例function setComponentValue(el, value) { const node findVueInstance(el) if (!node) return false const { version, instance } node if (version 3) { instance.ctx?.$emit?.(update:modelValue, value) return true } instance.$emit?.(input, value) return true }注意 Vue3 这里用的是update:modelValue如果组件的v-model带了参数名比如v-model:visible事件名就是update:visible得对应改。判断方法是在 Vue 面板里看组件的 props 名。还有一类更隐蔽的情况组件外面套了v-model但内部又做了一层格式化。比如日期组件要求传入的是Date对象或者特定格式的字符串你传个2024-01-01上去组件内部dayjs解析失败值变成空。这类问题只能靠试——先试字符串不行试时间戳再不行试Date对象。我遇到过某组件只认 ISO 格式带T的字符串折腾了半小时才试出来。5.3 表单校验与脏值判断填完值之后很多表单还有一步点提交时统一校验字段没变过就跳过。Vue 的校验库比如基于 async-validator 的那套通常是通过trigger: change或trigger: blur来触发字段校验的。如果你只派发了input校验不会跑提交时还是会报请填写xxx。解决办法是补派change和blurel.dispatchEvent(new Event(input, { bubbles: true })) el.dispatchEvent(new Event(change, { bubbles: true })) el.dispatchEvent(new Event(blur, { bubbles: true }))blur事件要注意它本身不冒泡但 Vue 里通过blur绑定时是通过addEventListener挂在元素上的所以不冒泡也能触发。不过如果你要派发给父级得用new FocusEvent(blur, { bubbles: false })这个细节别搞混。还有一个常被忽略的点某些表单会记录初始值快照提交时对比当前值和快照一样就不提交这个字段。这种情况你怎么填都没用因为它的判断逻辑压根不看 DOM。这种时候唯一的办法是走实例改数据让快照对比失效。这也是为什么我总说自动化脚本这东西能通一百个页面第一百零一个总能给你惊喜。6. 完整排查链路与工程化封装6.1 从值变了到数据没变的四步定位遇到填不进去的情况别急着改代码按这个顺序往下走基本能在几分钟内定位到具体环节。第一步确认数据到底变没变。打开开发者工具找到目标元素在控制台里$0.__vue__或者$0.__vueParentComponent看看绑定的数据当前是什么值。如果数据已经变了但界面没变那问题在渲染层如果数据没变继续往下。第二步确认事件有没有被监听到。在元素上手动加一个临时监听器$0.addEventListener(input, e console.log(收到, e.target.value))然后派发一次事件看控制台有没有输出。没输出说明事件根本没到元素上检查是不是被别的层挡住了或者元素选错了。第三步确认事件有没有被吞。检查元素的readonly、disabled状态检查el.composing标记检查是不是层级选错了拿到了外层容器而不是真正的输入框。这一步用console.log(el.tagName, el.type, el.readOnly, el.disabled)一次性打完。第四步确认值有没有被二次覆盖。派发事件之后等 100 毫秒再看数据如果变了又变回去说明有个 watcher 在监听并做了格式化或者纠正。这种情况得去看数据层的逻辑光在 DOM 层面折腾是解决不了的。这四步走下来我遇到过的九成问题都能定位。剩下那一成通常是页面用了 iframe 或者 Shadow DOM元素根本不在主文档里document.querySelector天然拿不到。这种得先穿透进去属于另一个话题了。6.2 封装一个能扛事的填充函数把上面所有要点收拢我平时用的工具函数大概是这样function fillInput(el, value, options {}) { const { triggerChange true, triggerBlur false } options if (!el) throw new Error(目标元素不存在) // 清理可能残留的输入法标记 if (el.composing) el.composing false // 用原型 setter 写值兼容混合框架场景 const proto el instanceof HTMLTextAreaElement ? HTMLTextAreaElement.prototype : HTMLInputElement.prototype const setter Object.getOwnPropertyDescriptor(proto, value).set setter.call(el, value) el.dispatchEvent(new Event(input, { bubbles: true })) if (triggerChange) { el.dispatchEvent(new Event(change, { bubbles: true })) } if (triggerBlur) { el.dispatchEvent(new FocusEvent(blur, { bubbles: false })) } return el.value String(value) }返回值这里值得说一下。我用el.value String(value)做一次校验是因为有些输入框会对值做格式化比如手机号自动加空格、金额自动加千分位写进去的值和你期望的可能对不上。返回false的时候你就知道要额外处理了比默默失败强得多。再配一个批量填充的版本async function fillForm(map, { delay 50 } {}) { const results [] for (const [selector, value] of Object.entries(map)) { const el document.querySelector(selector) try { const ok fillInput(el, value) results.push({ selector, ok }) } catch (err) { results.push({ selector, ok: false, error: err.message }) } // 给 Vue 的异步更新留出时间 await new Promise(resolve setTimeout(resolve, delay)) } return results }那个delay不是随便加的。Vue 的更新是批处理的连续快速填充多个字段时如果某个字段的输入会触发联动计算比如填了省份自动带出城市列表下一个字段的 DOM 可能还没渲染出来querySelector就会返回null。给个 30 到 80 毫秒的间隔实测下来能解决绝大部分时序问题。宁可慢一点也别在后面加一堆重试逻辑。6.3 异步等待与重试的正确姿势严格来说靠setTimeout等 DOM 是个不太优雅的做法但它在自动化脚本里是性价比最高的。更稳的方式是用MutationObserver监听 DOM 变化等目标元素出现再操作function waitFor(selector, timeout 3000) { return new Promise((resolve, reject) { const found document.querySelector(selector) if (found) return resolve(found) const observer new MutationObserver(() { const el document.querySelector(selector) if (el) { observer.disconnect() resolve(el) } }) observer.observe(document.body, { childList: true, subtree: true }) setTimeout(() { observer.disconnect() reject(new Error(等待 ${selector} 超时)) }, timeout) }) }这个函数在弹窗场景下特别有用。很多后台系统的表单是弹窗形式点新增之后要等动画播完、组件挂载完成输入框才真正存在于 DOM 里。用固定延时等待机器快了慢了都不准用 MutationObserver 则是一出现就动手既快又稳。我个人的习惯是两者结合先用waitFor等元素出现填完之后用短延时等联动生效。只用其中一种在某些页面上总会翻车。最后分享一个我自己踩出来的经验写这类自动化脚本千万别在控制台里反复手敲调试。页面刷新一次就得重来一遍效率极低。正确做法是把逻辑写成一个函数存在书签脚本或者浏览器扩展里刷新后一键执行每次改一行就在函数里改验证一次到位。这比在控制台里堆几十行临时命令高效太多也更容易发现那些只在特定数据下才暴露的边界问题——比如填了空字符串、填了超长文本、填了负数这三种情况几乎每个表单都会出点岔子。
