刚好之前在项目里踩过DynamoDB SaveBehavior相关的坑，来给你梳理清楚这两个问题：

1. 既然乐观锁可实现记录的安全写入，为何有人要禁用它？ #

乐观锁的核心是通过版本号校验避免并发写入冲突，但并不是所有场景都需要这种安全保障，甚至有时候它会成为阻碍：

• 无并发写入的场景：比如单进程的后台定时任务、初始化系统配置这类完全不会有多个写入请求同时发生的场景，版本校验的逻辑完全是多余的性能开销。用CLOBBER跳过版本检查，能减少一次条件判断的成本，提升写入效率。
• 全量覆盖写入的需求：如果你的业务逻辑就是要完全覆盖旧数据，比如每次更新都把整条记录的最新状态全量写入（比如同步外部系统的全量配置），旧数据没有任何保留价值，这时候版本控制反而会增加复杂度，直接用CLOBBER覆盖更简单直接。
• 数据迁移/修复场景：在批量导入历史数据、修复错误数据时，你需要强制覆盖旧的记录状态。如果开启乐观锁，可能会因为版本不匹配导致写入失败，反而拖慢迁移或修复的进度，这时候禁用乐观锁是更务实的选择。

2. 其他SaveBehavior的乐观锁状态是怎样的？使用UPDATE_SKIP_NULL_ATTRIBUTES等是否合理？ #

先明确各个SaveBehavior的乐观锁状态，以及它们的适用场景：

• UPDATE_SKIP_NULL_ATTRIBUTES：和UPDATE一样，启用基于版本属性的乐观锁。它和UPDATE的核心区别是对null属性的处理：UPDATE会把请求中的null属性从记录中移除，而UPDATE_SKIP_NULL_ATTRIBUTES会跳过这些null属性，不修改原有字段。这个行为非常合理，比如用户更新个人信息时，只修改手机号和地址（其他字段留空），既想保证并发写入的安全性，又不想误删其他已有的字段，用它就刚好合适。
• APPEND_SET：同样启用乐观锁。这个行为专门用于集合类型属性（比如StringSet、NumberSet）的追加操作，而不是覆盖。这类场景本身就很容易出现并发写入冲突（比如多个请求同时给用户追加标签），乐观锁能保证每次追加都是基于最新的记录版本，避免数据丢失，所以使用它完全合理。

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