先说一个让我记忆很深的场景那天我在做表格的行内编辑功能列表数据是接口返回的数组用户点了某一行后面的“设为默认”按钮我的代码写得非常简单直接this.list[index].isDefault true。控制台打点、Vue Devtools 里看数据全部显示已经改过来了但那行按钮的样式死活不变。我当时的第一个反应是“Vue 是不是出 bug 了”第二个反应是“我是不是少写了什么刷新方法”。这两句话我相信在 Vue 2 项目里摸爬滚打过的人都说过不止一遍。这个问题的标题就讲得很直白数组下标修改数据页面死活不更新。这篇踩坑实录就是要把它彻底讲清楚——包括 Vue 2 为什么会有这个问题、底层机制到底卡在哪、有哪些绕过去的办法、各自的代价和坑以及升级到 Vue 3 之后这个问题还存不存在。1. 复现现场一个数组下标赋值引发的“代码没跑吗”先别急着找解决方案我们把“案发现场”完整地还原一遍。因为只有把现场复现清楚了你才会知道这个坑到底长什么样它和“对象新增属性不更新”是不是同一类问题排查的时候才不会跑偏。1.1 最典型的翻车场景回顾假设你有下面这样一个组件list是从后端接口拿到的用户列表页面上用v-for渲染每一行有一个启用/停用的状态开关template div div v-for(item, index) in list :keyitem.id span{{ item.name }}/span button clicktoggle(index) {{ item.isActive ? 已启用 : 已停用 }} /button /div /div /template script export default { data() { return { list: [] } }, created() { this.list [ { id: 1, name: 张三, isActive: false }, { id: 2, name: 李四, isActive: false } ] }, methods: { toggle(index) { this.list[index].isActive true console.log(改完了, this.list[index].isActive) // true } } } /script你点按钮console.log打出来的值确实是trueDevtools 里this.list也确实是改掉了但页面上的按钮文字仍然是“已停用”。这不是什么并行更新、异步渲染的问题因为哪怕你在$nextTick里再检查一遍DOM 依然没有变。这就是“数组下标修改数据页面死活不更新”的标准现场。1.2 第一次排查时的心理活动与直觉误判没经验的开发遇到这种情况第一反应是怀疑自己哪里写错了。于是我开始逐项排查是不是v-for的 key 写错了改成index试试不行。是不是有别的代码把数据又改回去了在toggle里加了一堆日志没有。是不是事件绑定没生效打点发现方法确实执行了。是不是item根本不是响应式对象Devtools 里点开看明明有__ob__标记。最迷惑的一点在于数据变了视图没变。这在直觉上完全违背了 Vue 响应式系统的设计目标。而且你换成this.list.splice(index, 1, { ...item, isActive: true })去改页面又正常刷新了这说明不是list本身失去响应式而是“下标赋值”这种方式在 Vue 2 的响应式系统里有特殊的行为限制。我当时花了一整个下午把组件内部翻了个底朝天最后才发现问题根本不在我的业务代码而在 Vue 2 响应式系统对数组的“差别对待”。搞清楚之后有一种“原来如此”的释然但更多的是后悔——如果早点知道这个机制根本用不了这么久。2. 根因解剖Vue 2 数组响应式为什么会在下标这里“断掉”要彻底理解这个坑必须回到 Vue 2 响应式系统的底层原理。这不是为了让你去背源码而是因为只有知道了“断”在哪遇到变种问题时才不会慌。这一节我会把问题拆成三层来讲Object.defineProperty的边界、Vue 2 对数组的特殊处理、以及为什么官方明知道有坑却没有走“全量代理”的方案。2.1 Object.defineProperty 的底层限制Vue 2 的响应式核心是Object.defineProperty它能把对象的某个属性转成一个 getter/setter。当你访问属性时触发 getter当赋值时触发 setterVue 就在 setter 里做依赖通知从而触发重新渲染。问题在于Object.defineProperty的粒度和对象是“一对一”的它只能针对“已经存在的、明确定义的属性”做拦截。对于数组来说一个数组里可能有几百上千个元素如果要把数组的每个下标都定义成响应式属性代价非常大而且数组本身还有length这种特殊属性直接对length做拦截在语义上也很别扭。更关键的一点是在 JavaScript 里arr[0] hello这种操作本质上就是在调用底层的[[Set]]逻辑。如果这个对象属性的属性描述符里没有 setter那就走默认赋值。Vue 2 对数组元素之所以做不到拦截是因为它根本没有把每个下标都通过defineProperty包装起来所以下标赋值这条路径上没有 Vue 的 setter 可以被触发页面自然不会有任何反应。2.2 Vue 2 对数组做了“特殊处理”但留了三个口子很多人有个误区觉得 Vue 2 完全没有对数组做响应式处理这是不对的。Vue 2 在被观测数组的实例上重写了几个常见的会改变数组自身的方法包括push、pop、shift、unshift、splice、sort、reverse。也就是说你调用this.list.push(...)时Vue 内部会先执行原生的方法再额外触发依赖更新所以用push添加元素页面会正常更新。但官方文档明确写了两点限制利用索引直接设置一个数组项时例如this.list[index] newValue不会被检测到。直接修改数组的length时例如this.list.length 0不会被检测到。为什么“下标赋值”不被检测到因为在 Vue 2 的Observer实现里数组被处理时走的是observeArray它遍历数组已有元素把它们逐个变成响应式对象针对的是数组里的元素对象本身但数组索引本身并没有被逐个defineProperty。同时 Vue 只重写了上述 7 个方法并没有去重写[]操作符的赋值逻辑。于是this.list[index] newValue就变成了一条完全没有走 Vue 依赖收集与派发更新通道的“野路子”。2.3 为什么不用 defineProperty 代理数组下标看到这里你可能会问既然Object.defineProperty能做到Vue 2 为什么不干脆把数组的每个下标都包装成响应式属性像处理普通对象那样主要有几个考量性能和内存问题一个页面级的大数组动辄几百上千项而且很多情况下数组里的元素会被替换、删除、动态增加。如果对每个下标都做defineProperty初始化的开销会非常明显尤其在后端返回大量列表数据的场景下可能直接导致页面卡顿。索引数量不确定对象的 key 是固定的而数组的索引是动态的你push一个新元素就多了一个索引。Vue 需要在每个新增元素上都重新做响应式处理稍有不慎就会出现性能毛刺。length 的特殊性length在 JavaScript 数组里是一个诡异的属性你把length改小了会直接截断数组改大了会产生空槽位。对length做 setter 拦截会让很多原生数组操作出现不可预测的行为。所以 Vue 2 当时的取舍是不做下标的响应式拦截只重写 7 个会“自我变更”的方法同时用文档和社区经验告诉你“别用下标赋值”。这个设计在性能上的收益很明显但确实给开发者留下了形形色色的坑本篇踩坑实录就是其中之一。3. 操作对照清单哪些改数组写法能触发更新哪些是无效功根因讲完之后我们进入实操层面。我整理了一份“有效 vs 无效”对照清单覆盖最常见的数组修改操作。你遇到页面不更新的时候直接对照这份清单就能很快定位问题出在哪一种写法上。3.1 无效操作清单下标赋值、length修改先看看哪些做法是“看着合理实际上无效”的操作方式示例页面是否更新原因通过索引直接赋值this.list[0] newObj否没有触发 Vue 的 setter修改已有对象的属性this.list[0].name 新名字视情况而定如果对象属性原本就是响应式的会更新直接修改 lengththis.list.length 0否没走重写过的数组方法用替换整个数组this.list newArray是替换的是 data 属性的引用会触发 setter调用重写过的 7 个方法push/pop/shift/unshift/splice/sort/reverse是Vue 在方法内部做了依赖通知这里要特别提醒一种“视情况而定”的情况this.list[0].name 新名字。如果.name这个属性原本就在初始数据里声明过并且整个对象在进入data时被 Vue 递归观测过那这种修改是响应式的因为这里的“setter”拦截的是name属性而不是数组下标。你在第 1 节的复现场景里this.list[index].isActive true的isActive其实也属于这种情况——它是响应式属性所以数据变了页面也会更新。等等这不是自相矛盾吗第 1 节里说this.list[index].isActive true页面不更新这里又说this.list[0].name 新名字会更新关键区别在于对象是否已经存在于响应式系统中。如果list的初始值里就有{ isActive: false }那么 Vue 对这个对象做了defineProperty处理isActive是带 getter/setter 的所以this.list[0].isActive true是能触发更新的。那第 1 节的复现为什么没更新我承认我在 1.1 里刻意简化了场景但实际工作中最常踩的坑其实是数据是接口返回的列表初始为空数组接口数据到达后才赋值给list然后再修改嵌套对象属性——这种情况下Vue 在赋值时确实会做响应式处理原理上也能更新。但更常见的真实原因是下面这几类初始data里根本没有isActive这个字段或者你修改的“下标”对应的元素是后加的Vue 没有提前把它变为响应式或者根本就不是对象属性变化而是要把整个数组项替换掉——例如this.list[index] newObj。所以先别急着对号入座实际项目里的“不更新”往往是几种因素叠加。为了更贴近真实高频场景下面这个表格才是你真正需要的操作方式示例页面是否更新适用注意点用替换整个数组this.list newArray是最简单但会丢失数组引用用splice替换指定项this.list.splice(index, 1, newObj)是官方推荐用$set修改指定项this.$set(this.list, index, newObj)是通用能新增属性替换整个对象后重新赋值this.list.splice(0, this.list.length, ...newArray)是适合整体更新列表直接通过索引改数组项this.list[0] newObj否无效别用修改数组长度截断this.list.length 0否用splice(0)代替直接改对象里已声明属性this.list[0].name x若属性存在则是前提是对象已经过响应式处理给对象新增未声明属性this.list[0].age 18否需要$set3.2 有效操作清单splice、替换引用、$set 等下面这些操作无论是想替换单项、还是更新整个列表都是可靠的this.$set(this.list, index, newValue)最通用既能改已有项也能给对象新增属性。this.list.splice(index, 1, newValue)官方文档推荐用于下标替换的方法。this.list [...this.list]或this.list newList直接替换整个数组引用触发 data 属性的 setter。调用重写的 7 个方法例如push、pop、shift、unshift、splice、sort、reverse。对数组项内的已有属性赋值前提是属性在初始化时就存在且对象已经过 Vue 的响应式处理。实际上你在开发中只要遵循一个原则就好了不要让数组原地“变”而是让数组的引用“换”或者通过 Vue 暴露的 API 来改。v-for重新渲染需要依赖一个变更信号信号天然来自响应式系统你绕过了它它自然就不知道什么时候该重新渲染。3.3 容易被误判的“看起来不更新”场景有些情况明明数据和 DOM 都没问题但看起来就像“不更新”这种很容易误判成响应式 bug实际是别的原因在捣乱。用了 index 作为 v-for 的 key当你插入一条数据或删除中间一条时因为 key 没变Vue 会复用已有的 DOM 节点导致内容渲染错位看起来就像“页面没更新”。比如你删了第一行但第一行显示的还是旧数据因为复用了。这种情况下用item.id作为 key 就解决了。父组件数据更新子组件没有跟着更新Vue 的更新是组件级别的子组件可能因为自身没有绑定任何响应式依赖而“偷懒”不重新渲染。这时需要在子组件里加一个依赖于你希望更新的数据的计算属性或者用key强制重建子组件。对象属性在初始 data 里不存在比如初始值是{ name: , age: 0 }后续你给对象加了一个gender属性页面能感知到name、age的变化但感知不到gender。这个跟数组下标不更新的原因一样都是依赖的 key 在初始化时没有被 Vue 观测到。排查页面不更新问题时建议先用一遍 3.3 这种“外部因素”检查再去怀疑响应式底层问题。很多时候你以为踩了框架的坑实际上是 key 或者生命周期顺序的问题。4. 六个可用方案逐个拆解从 $set 到 $forceUpdate 都有代价知道了为什么不行也知道了哪些写法行这一节我们把可行的方案集中拆解一遍。每个方案我会讲用法、原理、适用场景和代价方便你按需选择。4.1 方案一this.$set / Vue.set — 覆盖率最高$set是 Vue 全局Vue.set的实例方法。用法this.$set(this.list, index, newValue)在 Vue 2 源码里$set的逻辑大致是这样如果目标是数组就调用target.splice(key, 1, val)因为splice是被 Vue 重写过的方法能触发视图更新如果目标是对象就调用defineReactive给对象定义新的响应式属性。所以你可以把$set当作一个“内部帮你做正确操作”的万能工具。它最典型的应用场景有两个数组下标替换、对象新增属性。代码示例// 数组第 index 项整个替换 this.$set(this.list, index, { name: 新名字, isActive: true }) // 给列表项的某个对象新增属性 this.$set(this.list[index], isActive, true)代价和注意点$set只能保证目标变为响应式并触发更新但如果index超出了数组长度或者目标不是响应式对象它也不会生效。而且每次调用$set都会执行一次响应式包装频繁操作大数组时性能会比原生操作略差。它是我个人最推荐的首选方案因为语义清晰、不改变数组引用、也不会引起父子组件之间的额外副作用。4.2 方案二splice 替换法 — 兼容性最稳官方文档里提到“利用索引直接设置一个数组项”时给的建议就是splice。示例this.list.splice(index, 1, { ...this.list[index], isActive: true })splice之所以有效是因为 Vue 2 重写了数组的splice方法在调用原生方法之后会额外触发ob.dep.notify()告诉那些依赖该数组的渲染 watcher“这个数组变了请重新渲染”。这个方案的好处是不需要额外引入 API所有 Vue 2 项目天然支持。如果只是替换数组中的一个元素它逻辑最直观。配合展开运算符可以很方便地基于原对象生成新对象避免引用共享导致的后续 bug。代价如果你要改的是一个很深层级的嵌套对象属性splice就显得有点笨拙。另外需要注意splice的替换目标是一个新对象而不是把原对象改完之后再塞回去。如果你直接用splice(index, 1, this.list[index])是不起作用的等于你把同一引用塞回去splice方法确实触发了通知但由于新旧值引用相同Vue 在hasChanged判断时可能直接跳过更新。所以一定要用一个新对象替代。4.3 方案三整体重新赋值 — 最简单粗暴如果你不关心数组引用是否变化最简单的方式就是整体替换this.list[index] newObj this.list [...this.list]或者干脆this.list this.list.map((item, i) i index ? { ...item, isActive: true } : item )this.list ...走的不是数组索引的 setter而是list这个 data 属性的 setter它一定是响应式的页面一定会刷新。这也是为什么“数组整体替换”是万金油中的万金油。代价整体替换会导致v-for对整份列表做差量更新虽然 Vue 有虚拟 DOM diff 能最小化 DOM 操作但所有子组件如果传了item作为 propsitem引用变化可能会导致子组件重新渲染。对于超大列表这种方案的开销明显高于$set或splice。它适合列表规模不大、更新频率不高的场景。另外还要注意如果你在计算属性里返回了this.list的派生值整体替换会重新触发计算属性而splice不会影响派生值的重新计算这也是选择方案时需要考虑的因素之一。4.4 方案四$forceUpdate — 下策中的下策你肯定在别人的代码里见过this.$forceUpdate()。这个方法的作用是强制当前组件实例重新渲染。this.list[index].isActive true this.$forceUpdate()为什么它能起作用因为$forceUpdate会直接调用组件的_watcher.update()绕过依赖通知的流程强制组件重新执行渲染函数并更新 DOM。但你一定要清醒地认识到$forceUpdate不是“万能刷新键”它有几个很严重的副作用它只影响当前组件实例不会强制子组件重新渲染。如果你的页面结构是三层嵌套组件子组件的数据更新仍然可能看不到。依赖computed缓存的结果可能不会被重新计算因为 computed 的缓存依赖的是响应式依赖而不是$forceUpdate。它是一种“逃避问题”的做法会掩盖真正的数据响应式缺陷导致后续维护者以为数据是响应式的继续用错误写法埋下更多坑。什么时候才值得用我个人的判断标准是临时排障时用一下确认问题确实和响应式无关然后立即改成正确写法。千万别在生产代码里长期依赖它。长期依赖$forceUpdate的项目代码里通常到处是这种补丁后期根本没办法维护。4.5 方案五数据结构换型 — 从根源避开如果你在开发新功能时提前预见到“这块列表数据经常要改指定项”那可以在数据源层面就避开数组。一个非常实用的替代方案是用对象代替数组。比如用一个以 id 为 key 的对象来存储列表数据data() { return { userMap: { 1: { id: 1, name: 张三, isActive: false }, 2: { id: 2, name: 李四, isActive: false } } } }修改某个用户的状态时this.$set(this.userMap, userId, { ...this.userMap[userId], isActive: true })这样依赖的是对象的属性 setter而不是数组的索引 setter。只要 object 的属性在初始化时存在或者用$set新增更新就会非常自然。模板里用v-for遍历对象也没有问题div v-for(item, id) in userMap :keyid button{{ item.isActive ? 已启用 : 已停用 }}/button /div代价对象遍历的顺序在旧浏览器上可能不完全可靠但现代浏览器基本都保持插入顺序。另外如果你要保证“数组方法”如push、filter这种操作换成对象结构后需要稍微多写几行代码。不过换个角度想能从根本上绕开响应式系统的限制这点代码量是值得的。4.6 方案六深度克隆后赋值 — 适合整表更新有些场景不是改一个元素而是从接口拿到一份新的列表需要整体替换。这时最稳的写法是this.list res.data.map(item ({ ...item, someFlag: false }))或者更简单this.list JSON.parse(JSON.stringify(res.data))这种方式比逐个 splice 更高效而且不容易漏掉新增的属性。代价是如果列表特别大深拷贝会有一定性能损耗但一般业务列表不会有这个问题。它的核心优势是你还在源头就重新做了一次响应式转换一旦赋值给data中的list所有新增对象都会自动被 Vue 观测后续操作不会再出现“对象新增属性不更新”的辅助问题。方案选型时我给一个非常实际的建议常规单条修改 → 用$set或splice。整表刷新 → 用整体赋值。频繁修改嵌套数据 → 考虑换对象结构。实在需要临时查看效果 → 才用$forceUpdate但记得之后改回来。5. 排查标准链路遇到页面不更新按这个顺序查最省时间踩坑多了之后我总结出了一套排查页面不更新问题的标准链路。它不是针对某一个根因的而是从头到尾把可能性逐个排除最后定位到底层原因。这里分享出来下次遇到类似问题就不用“怀疑人生”了。5.1 第一步先确认数据真的改了还是渲染层问题很多时候页面不更新不是因为响应式系统坏了而是因为数据压根没改到、或者渲染层在别的地方出了问题。所以在动手排查前先做三件事在事件处理函数里console.log打点确认数据确实已经修改。在$nextTick回调里再打一次点确认数据修改后、DOM 更新前后的状态。打开 Vue Devtools点击对应组件看data里的值是否真的变了。如果 Devtools 里显示的数据和你期望的一致但页面没有变基本可以确定是渲染层或依赖追踪的问题如果 Devtools 里数据都没变那就是你的代码根本没执行到这一步别急着怪框架。5.2 第二步判断命中哪一类“检测不到”如果确认是响应式问题接下来判断是以下哪一类的“检测不到”数组下标赋值this.list[index] newVal→ 走$set或splice。修改数组长度this.list.length 0→ 用splice(0)代替。对象新增属性this.obj.newField val→ 用$set或初始化时声明。对象属性未在初始 data 中定义在data里补齐字段或$set。用一张表对照是最快的现象原因分类推荐修复改了数组下标数据变了页面不变数组索引赋值未拦截$set/splice/ 整体赋值清空数组页面仍显示旧数据修改 length 未拦截splice(0)/list []给对象添加新字段页面没反应对象属性不存在$set/data里提前声明数据变了子组件没变子组件未依赖该数据检查 props 和 key列表操作后渲染错乱key 用错换成业务唯一 id5.3 第三步检查 key 是否在捣乱如果数据确实在 Devtools 里变了页面也“动”了但是内容对不上号比如删除一条后后面一条顶到了前面、插入后顺序错误那优先怀疑 key。v-for的 key 是 Vue 虚拟 DOM diff 的核心依据。如果你用了 index 作为 key在中间插入或删除元素时Vue 会误以为每个位置的元素只是内容变化会尽量复用现有 DOM 节点导致状态错乱。它的典型表现是“数据好像更新了但页面表现不对”这常常被误报成“不更新”。正确做法是优先用业务主键比如用户 id、商品 sku如果确实没有唯一字段再考虑 index但心里要清楚插入/删除场景会有问题。还有一种做法是用组合 key比如index item.id但不建议为了规避复用问题这么写因为组合 key 在插入时依然可能引发不必要的重建。5.4 第四步确认不是非响应式数据最后一个容易被忽略的坑有些数据可能根本不是响应式的。比如你在data外面挂的属性、在created里临时挂到this上的变量、由第三方库直接修改的数据这些对象本身没有经过 Vue 的响应式处理自然改动后页面不会更新。判断方法也很简单在 Vue Devtools 里看该数据节点下有没有一个__ob__标记或者看对象属性是否被转成了 getter/setter。没有的话说明这个对象压根没有被 Vue 观测$set也不一定管用它只能把数据变成响应式但如果目标引用本身没有与渲染过程建立依赖更新依然不会触发渲染。这种情况下与其纠结响应式不如把它挪到data里重新赋值。排查链路走完你会发现自己 90% 的“页面不更新”问题都能归到上述某一类而且修复方式都很明确。这个流程的本质思路是先确认数据状态再确认渲染依赖最后看引用和 key 是否干净。不要一上来就怀疑框架 bug框架的边界都是可以通过源码或文档预测的。6. Vue 3 的解法变化Proxy 接管后旧坑还剩多少如果你已经切换到 Vue 3或者正准备从 Vue 2 迁移可能会很关心这个问题数组下标赋值不更新这个坑到了 Vue 3 还会存在吗这一节我就带你把 Vue 3 的响应式底牌翻一遍以及要特别留意的迁移注意点。6.1 Vue 3 reactive 的 Proxy 拦截逻辑Vue 3 的响应式核心换成了Proxyreactive方法会为对象或数组创建一个代理Proxy。Proxy能拦截 JavaScript 对象上几乎所有的操作包括set、get、deleteProperty、has、ownKeys等。也就是说Vue 3 里你直接写const state reactive({ list: [{ name: 张三, isActive: false }] }) state.list[0].isActive true state.list[0] { name: 新用户, isActive: false } state.list.length 0这些操作全都能触发更新。因为state.list本身就是一个 Proxy 代理你访问state.list[0]时触发的是一个get陷阱赋值时触发的是set陷阱Vue 在set陷阱里如果能确定目标和 key 都是响应式的就会触发依赖更新。数组的length变化、索引赋值、对象新增属性在 Proxy 面前全部是“常规操作”。所以答案是在 Vue 3 里reactive包裹的数组通过下标修改元素、直接修改 length、给对象动态加属性这些动作都天然是响应式的旧坑不存在了。6.2 同样的需求在 Vue 3 里怎么写用 Vue 3 script setup的写法之前的复现场景会变成这样script setup import { reactive } from vue const state reactive({ list: [ { id: 1, name: 张三, isActive: false }, { id: 2, name: 李四, isActive: false } ] }) function toggle(index) { state.list[index].isActive true } /script template div v-for(item, index) in state.list :keyitem.id span{{ item.name }}/span button clicktoggle(index) {{ item.isActive ? 已启用 : 已停用 }} /button /div /template不再需要$set不再需要splice也不需要整体赋值。数据变了视图就会跟着变这才符合正常直觉。但是这里有个容易踩的新坑如果你用ref来存数组那么用ref的时候需要小心。ref内部会为对象值调用reactive所以state.list[0].isActive true也有效。但如果你是直接重新赋值state.value newArray而不是state.value[0] ...那没问题重新赋值本身就会触发更新。6.3 迁移时要注意的新行为虽然 Vue 3 解决了“数组下标修改”的问题但从 Vue 2 迁移到 Vue 3 时以下几种行为差异还是要格外留意的响应式对象的属性动态新增没问题但delete也能被拦截了。在 Vue 2 里删除一个对象属性可能不会触发更新在 Vue 3 里delete state.obj.xxx也会触发更新行为更符合预期但如果你在代码里依赖旧行为规避渲染迁移后可能出现额外的渲染次数。reactive返回的是代理对象不是原对象。如果你把一个reactive对象赋值给一个普通变量再修改普通变量不一定影响原对象。所有数据访问都应该通过代理对象来做。Object.freeze、Object.seal过的对象在reactive里可能不会被正确代理需要特别处理。数组的includes、indexOf、lastIndexOf等方法在 Vue 3 的代理对象上运行时返回的结果可能和原生数组有细微差别因为代理对象内部引用和原始对象引用不一致第三方库有时会遇到这类兼容问题。从 Vue 2 升级到 Vue 3尤其是老项目不要只想着“解决旧坑”还要抽时间把文档里关于 Proxy 响应式边界的那一节读一遍。底层机制变了很多“经验之谈”需要更新。如果你还在用 Vue 2 维护老项目那本篇正文里提到的这些方案就是你日常的救命稻草。我的个人建议很简单把“数组下标赋值”和“修改 length”这两种写法当成禁词一样规避日常开发一律用$set或splice遇到老代码里的这些问题尽量抽时间统一改造。数据响应式这条链路一旦保持干净后续的 bug 排查会省出大量时间这个成本投得绝对值。
