MongoDB 无自增ID机制，计数器跳号源于应用层逻辑而非数据库缺陷；findAndModify不参与事务回滚，跨集合操作无法保证一致性；连续ID需求与MongoDB分布式设计目标相悖，应改用PostgreSQL/MySQL或应用层生成编号。
MongoDB 本身没有自增 ID，所谓“回滚后不连贯”一定是你在应用层模拟的计数器逻辑出了问题，不是数据库行为。
为什么 findAndModify 更新计数器后事务回滚，ID 还是跳号了
你在事务里调用 db.counters.findAndModify 获取并递增 seq 字段，接着写业务数据；但事务最终 abortTransaction() ——此时计数器已+1，而业务文档没写入，ID 就空耗了。
-
findAndModify是原子操作，但它不在事务上下文中被回滚：它作用于独立集合（如counters），不能跨集合参与多文档事务的一致性保障 - 哪怕你把它放在
session.startTransaction()之后，InnoDB 式的“回滚即撤销所有变更”在 MongoDB 里不成立 - 并发场景下多个事务同时读到同一旧值，各自执行
$inc，部分成功落盘，部分因写冲突失败，但计数动作不可逆
想让数字 ID 连续？先确认你真需要它
连续 ID 是强一致性模型下的副产品，而 MongoDB 的设计目标是分布式可用性与写扩展性。如果你的业务逻辑依赖“ID 必须严格递增、无空洞、可预测”，说明数据建模和存储选型存在错配。
- 订单号、流水号等对外暴露的编号，应由应用层生成（如时间戳+机器ID+序列号），而非依赖数据库计数器
- 内部关联用的
_id完全可以用ObjectId，它前 4 字节是秒级时间戳，足够支持按插入时间粗略排序 - 若必须用数字主键且要求连续，建议改用 PostgreSQL 或 MySQL，MongoDB 不适合这类场景
如果非要用计数器，怎么降低跳号概率
无法彻底消除跳号，但可以收窄发生条件：
- 避免在事务中调用
findAndModify：改为先取号（带重试）、再写业务数据，把“取号失败”作为前置校验，而不是嵌套在事务里 - 给计数器集合加唯一索引（如
{_id: 1, timestamp: 1}），配合应用层幂等控制，防止重复取号 - 用
findOneAndUpdate替代findAndModify（后者已弃用），并显式设置{upsert: true, returnDocument: "after"} - 监控
db.counters的写频次和失败率，跳号突增往往意味着上游并发激增或事务超时配置过短
最常被忽略的一点：很多人试图用 ObjectId 的时间戳部分做“伪自增排序”，却没意识到它的后半段含随机值——高并发插入时，ObjectId A > ObjectId B 完全可能对应插入时间更晚。这不是 bug，是设计使然。别拿它当 MySQL 的 AUTO_INCREMENT 用。
