应根据场景选择：空条件用 estimatedDocumentCount()（快但不准），精确计数必须用 countDocuments({}).hint("_id").maxTimeMS(30000) 并检查 balancer 状态。
count() 在 Node.js MongoDB 驱动中早已被弃用，实际慢的不是它——而是你误用了 countDocuments({}) 却没加优化，或者在分片集群里指望 estimatedDocumentCount() 返回准数。
为什么 countDocuments({}) 慢得明显
它不是“慢”，是“必须扫”。countDocuments() 会真实路由到每个 shard（或 replica set 主节点），执行带 _id 排序的游标遍历，再由 mongos 合并总数。尤其当集合没建有效索引、或 filter 不为空时，很容易触发全表扫描。
- 不传空 filter：
countDocuments()会报TypeError（PyMongo）或静默失败（部分旧 driver 版本） - 没加
.hint("_id_")：即使只数总量，也可能绕过_id索引，走 collection scan - 没设
maxTimeMS：遇到大集合或网络抖动，请求可能卡住几十秒，拖垮整个服务 - balancer 正在运行：分片迁移中调用
countDocuments({})，结果可能重复或遗漏，且无法重试
estimatedDocumentCount() 快但不准的根本原因
它根本不去读文档，只查 WiredTiger 引擎维护的内存元数据 ns->nrecords。这个值在单机或副本集里通常够用，但在分片集群里有三类硬伤：
- 迁移中：源 shard 和目标 shard 同时持有 chunk 副本 → 重复计数
- 孤儿文档：迁移中断后残留、不被路由层识别 → 彻底丢失
- 元数据延迟：WiredTiger 刷新有 lag，
estimatedDocumentCount()可能比真实数少几秒到几十秒
这不是 bug，是设计使然——它压根不承诺一致性，只承诺快。
Node.js 中正确切换的实操要点
别无选择：空条件用 estimatedDocumentCount()，有业务语义依赖的场景必须用 countDocuments({}).hint("_id_").maxTimeMS(30000)，并前置检查 balancer。
- Java Spring Data 用户注意：
mongoTemplate.count()底层就是countDocuments()，别被名字骗了；真正快的是mongoTemplate.getCollection("col").estimatedDocumentCount() - Node.js + Mongoose：直接调
Model.estimatedDocumentCount()，它返回 Promise，无需额外包装 - 不要在分页总数、配额判断、幂等 key 生成等地方用
estimatedDocumentCount()——波动值会直接导致逻辑错乱 - 如果必须精确又不能停 balancer，唯一办法是缓存 + 定期异步校准（比如每小时跑一次
countDocuments({})更新 Redis）
最容易被忽略的兼容性陷阱
estimatedDocumentCount() 在 unclean shutdown（如 kill -9 mongod）后可能严重失真，WiredTiger 不保证元数据原子落盘。而 countDocuments({}) 虽慢，但每次都是实时算的，结果可重现。
也就是说：快 ≠ 可靠，准 ≠ 实时，而“既快又准”在分片 MongoDB 里是个伪命题——你得先想清楚，这次 count 是给监控看的，还是给订单系统扣减用的。
