$inc 是 MongoDB 中对数值字段做原子自增最可靠、最轻量的方式，它天然规避了“读-改-写”导致的竞态问题，但必须配合正确的查询条件和索引，否则可能意外更新多条或漏更新。
直接说结论：用 $inc 是 MongoDB 中对数值字段做原子自增最可靠、最轻量的方式，它天然规避了“读-改-写”导致的竞态问题，但必须配合正确的查询条件和索引，否则可能意外更新多条或漏更新。
为什么不能用 find + update（非原子方式）
常见错误是先 find() 读出当前值，再在应用层计算新值，最后 updateOne() 写回去。这种模式在并发场景下必然出错——两个请求几乎同时读到 count: 5，都算出 6，最终只加了 1 次而不是 2 次。
这类问题不会报错，只会静默丢失更新，线上排查极难。MongoDB 服务端不参与逻辑计算，所有“业务逻辑型更新”都该尽量下沉到原子操作里。
无序列表说明关键风险点：
- 应用层计算引入延迟窗口，越复杂的逻辑（比如带条件判断的自增）风险越大
- 即使加了应用层锁（如 Redis 分布式锁），也增加系统耦合与失败路径
- 事务（
session.startTransaction()）能兜底，但开销大、有超时限制，纯数值自增完全没必要
$inc 的基本用法与安全边界
$inc 是服务端原生操作符，整个更新在存储引擎层完成，无需返回旧值、不触发应用逻辑、不可中断。它只接受数字（int、long、double），不支持字符串数字或 null。
正确示例（Node.js 驱动）：
db.collection.updateOne(
{ _id: ObjectId("...") },
{ $inc: { views: 1 } }
)
注意几个硬性约束：
- 目标字段必须已存在且为数值类型；如果字段不存在，
$inc会自动创建并设为增量值（例如从无到views: 1） - 增量值可为负数（
{ $inc: { balance: -5 } }），也支持小数（{ $inc: { score: 0.5 } }） - 不能对嵌套字段的某个子属性单独
$inc，除非路径明确（如"stats.likes"） - 若匹配到 0 条文档，操作静默成功（matchedCount = 0），不会报错也不会创建文档
并发高时必须加唯一条件 + 索引
$inc 本身原子，但“更新哪一条”由查询条件决定。如果条件太宽泛（比如只用 { status: "active" }），多个请求可能同时匹配到同一批文档，而 updateOne 只改第一条，其余被忽略——这看起来像自增失效，实则是逻辑误配。
真实高频场景（如用户积分、文章阅读数）应满足：
- 查询条件必须能精确命中单个文档，典型的是
{ _id: ... }或带业务唯一键的组合（{ userId: "u123", itemId: "i456" }） - 确保查询字段已建索引，否则
$inc操作可能触发全表扫描，拖慢响应且加剧锁竞争 - 避免在分片集群中对非分片键字段做
$inc，否则路由到多个分片，性能陡降
一个易忽略的坑：updateMany 配 $inc 是合法的，但除非你明确要批量调整（比如给所有老用户补发 100 积分），否则极易误用。生产环境建议默认用 updateOne 并检查 result.matchedCount === 1。
整数溢出与精度问题怎么处理
MongoDB 的数值类型底层依赖 BSON，Int32 最大值是 2147483647，Int64 是 9223372036854775807。如果业务上可能突破这些值（比如计数器累计百亿次），别硬扛：
- 优先考虑是否真需要精确计数——很多场景用近似值（HyperLogLog）、分桶统计或异步聚合更合理
- 如果必须精确，改用
Double类型（注意浮点精度丢失，9007199254740992 + 1 === 9007199254740992） - 避免在应用层做“超过阈值则重置”的逻辑，那又回到非原子陷阱；可用
$max/$min配合$inc做安全截断（但语义已不同）
真正麻烦的不是溢出本身，而是溢出后继续 $inc 会静默绕回（Int32 超限变负数），监控日志里看不到异常，只有业务数据突变才暴露问题。
