使用扩展运算符更新嵌套对象是否比reactive forms性能更低？

你当前使用扩展运算符全量复制对象赋值的实现方式，确实会在大体积、深嵌套对象场景下出现运行速度变慢、事件触发过于频繁的问题，核心原因如下：

• 运行速度变慢的核心逻辑
  扩展运算符本质是浅拷贝，修改深层属性时你需要手动逐层展开每一层父对象，相当于每次修改单个属性，都要重新创建该属性所有上层父对象的副本。对象嵌套越深、体积越大，创建副本的内存开销、计算耗时就越高，和局部更新的方案相比，性能损耗会随着对象复杂度上升线性增长。
  另外如果你用了Angular默认的变更检测策略，每次给this.currentData赋新的对象引用，都会触发当前组件及其所有子组件的全量变更检测，哪怕你只修改了一个用户名属性，也要跑一遍所有关联视图的更新校验逻辑，额外开销极高。
• 事件频繁触发的原因
  每次赋值新对象引用，所有依赖currentData的逻辑都会被触发：包括子组件的ngOnChanges生命周期钩子、对象变更的订阅回调、绑定的视图更新等，哪怕99%的属性值都没有发生任何变化，就会产生大量无意义的重复事件调用。

你提到的this.form.get('user.name').patchValue('Jonas')这类响应式表单API，恰好是为了解决这类场景设计的：

• 只更新你指定的目标字段，不需要重建整个表单对象的引用，不需要逐层复制上层对象，更新开销只和你修改的字段数量有关，和对象整体复杂度无关。
• 响应式表单的变更通知、校验、视图更新都是字段粒度的，修改哪个字段就只会触发对应字段的相关逻辑，不会触发全量的事件回调和变更检测，深嵌套大对象场景下性能优势非常明显。

• 表单类的状态管理优先使用Reactive Forms提供的patchValue/setValue方法做局部更新，避免手动用扩展运算符做全量对象复制赋值。
• 如果是非表单场景的复杂对象管理，可以搭配ChangeDetectionStrategy.OnPush变更检测策略，或者使用不可变数据增量更新工具，减少不必要的变更检测触发。

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