Polymer 2递归渲染问题排查：this.push与this.set的行为差异

首先得明确，这两种操作在数组的内存引用、变更触发逻辑上有本质区别，结合Chromium的V8引擎特性，很可能是这些差异导致了行为不一致：

1. this.push 的工作逻辑 #

push 是对原数组的原地修改（mutation）：

• 它不会改变数组的内存引用，只是在原数组的末尾添加元素，同时更新数组的length属性；
• 如果你的代码里有监听数组变化的逻辑（比如框架的状态追踪、DOM绑定），每次push都会触发一次细粒度的变更通知——Chromium的V8引擎会保留原数组的「隐藏类」（hidden class），这种增量修改的逻辑对引擎来说是可预测的，能正确同步所有依赖这个数组的逻辑。

2. this.set 替换整个数组的潜在问题 #

当你用this.set直接替换整个数组时，本质是替换了数组的内存引用：

• 新数组是一个全新的对象，V8会为它创建新的隐藏类，如果你的代码逻辑依赖原数组的隐藏类优化（比如某些底层的性能优化、状态监听），就可能出现不兼容；
• 如果this.set的实现只是简单的属性赋值（比如this.array = newArray），而没有触发对应的变更通知（比如框架的状态更新钩子、观察者模式的notify），那么依赖这个数组的UI或逻辑就不会感知到变化，导致「看起来无法正常运行」；
• 还有一种可能是Chromium的旧版本V8在处理数组引用替换时存在bug，比如数组的length属性没有被正确同步，或者某些异步更新的时序问题导致新数组还没完全初始化就被使用。

排查建议 #

给你几个具体的排查方向：

• 先看this.set的源码实现：它是不是只做了属性赋值，还是会调用更新通知？比如对比this.push的内部逻辑——很多自定义Store类里，push会在调用数组原生push后自动触发更新，而set可能漏掉了这一步；
• 打印数组的引用地址：在this.set前后分别console.log(this.array)，看新数组是不是完全替换了旧引用，同时检查监听逻辑是不是只监听了数组内容变化，没监听引用变化；
• 测试Chromium的不同版本：如果是旧版本，升级到稳定版试试，说不定是V8引擎的已知bug；
• 强制触发更新：如果是前端框架场景，在this.set后手动触发一次更新（比如React的forceUpdate、Vue的$forceUpdate），看是否能恢复正常，验证是不是更新没触发的问题。

内容的提问来源于stack exchange，提问作者tag42git