使用Mongoose更新数据的最佳实践是什么？两种实现方式该如何选择？

两种更新方式没有绝对的优劣，核心差异在于适用场景不同，具体对比和推荐如下：

两种方式的核心差异 #

1. 直接调用模型更新方法（updateOne/updateMany等） #

示例：User.updateOne({username}, {$set: {age}})

优势

• 性能更优：仅发起1次数据库请求，无额外查询开销，适配高并发场景
• 原子性强：更新操作在数据库层面原子执行，天然避免查询到保存之间的并发修改冲突，不会出现写丢失问题
• 支持批量操作：可一次性更新大量符合条件的文档，批量处理效率远高于逐文档操作

劣势

• 默认不触发save中间件，仅触发对应的update系列中间件，如果你把业务校验逻辑写在pre('save')钩子中，这类更新操作不会执行对应逻辑
• 默认关闭字段校验，需要手动添加runValidators: true配置才会执行Schema定义的字段规则，容易写入非法数据
• 无法支持复杂的更新前业务判断，所有判断逻辑只能写在查询条件或者更新操作符中，复杂逻辑的实现成本和维护成本极高

2. 先查询再修改后调用save()方法 #

示例：

const user = await User.findById(userId)
user.age = age
user.save()

优势

• 灵活性极高：可以拿到完整的文档数据做任意复杂的业务逻辑判断、字段计算，比如更新前校验用户余额是否足够、关联修改嵌套字段等，代码可读性和可维护性更强
• 默认触发pre('save')/post('save')中间件，适配绝大多数基于save钩子做业务逻辑封装的项目
• 默认自动执行Schema字段校验，不需要额外配置即可保证写入数据符合规则

劣势

• 性能偏低：需要发起2次数据库请求（查询+保存），高并发场景下IO开销会被放大
• 存在并发冲突风险：如果查询到保存的间隙有其他请求修改了同一份文档，会覆盖其他请求的修改，也就是写丢失问题，需要手动开启乐观锁解决
• 完全不适合批量更新场景，逐文档查询保存的性能极低

适用场景 #

优先选择直接调用模型更新方法的场景： #

• 无复杂逻辑的简单字段更新，比如更新用户最后登录时间、标记订单已删除等
• 批量更新多文档的场景
• 并发量高、对数据一致性要求高的核心业务更新场景

优先选择先查后存save()的场景： #

• 更新前需要做复杂业务逻辑判断、字段计算的场景
• 项目逻辑重度依赖save系列中间件，适配update钩子成本较高的场景
• 更新逻辑涉及多层嵌套字段修改，用update操作符实现复杂度极高的场景

官方推荐最佳实践 #

Mongoose官方没有强制要求统一使用某一种更新方式，仅给出以下通用规范：

• 使用updateOne/updateMany等模型更新方法时，默认添加runValidators: true和context: 'query'配置，开启字段校验，避免非法数据写入：

  User.updateOne({ username }, { $set: { age } }, { runValidators: true, context: 'query' })
  

• 使用先查后存方案时，如果业务存在并发修改可能，要在Schema中开启optimisticConcurrency: true，用内置的__v版本键实现乐观锁，出现版本冲突时会抛出错误，可自行捕获后做重试处理
• 涉及多文档事务的场景，优先用Session配合原子更新方法实现，不要拆分多个save操作
• 不要为了追求性能强行把复杂业务逻辑塞到update操作的条件中，过度复杂的update语句会大幅提升后续维护成本

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