必须使用 countDocuments() 进行带条件的精确统计，它支持查询条件、结果准确且是官方唯一推荐方式；estimatedDocumentCount() 仅适用于无条件的大致统计，不支持查询参数。
直接用 countDocuments()，别用旧版 count()。它返回精确值、支持查询条件、行为稳定，是当前 MongoDB 官方唯一推荐的统计方式。
什么时候必须用 countDocuments()
只要你的统计带条件（比如 { status: "active", createdAt: { $gte: ISODate("2025-01-01") } }），就必须用 countDocuments()。它会真实扫描匹配文档，结果 100% 准确。
- 旧版
count()在分片集群或存在删除未清理时可能返回错误值，MongoDB 4.0+ 已明确弃用 -
estimatedDocumentCount()不接受任何查询参数，只适合查“整个集合大概多少条”，不能加条件 - 如果你写
db.coll.find(query).count()，底层实际调用的仍是已弃用的count()，等价于错用
countDocuments() 的性能怎么控制？
它本身不走索引，但查询条件部分会——所以关键在 query 是否能命中索引。
- 确保查询字段（如
status、user_id）有单列或组合索引，否则全表扫描，大集合下明显变慢 - 避免在
countDocuments()中用正则表达式（$regex）、$where或全量数组匹配（$in超过几千项），这些基本无法利用索引 - 如果只是判断“是否存在至少一条”，可用
limit(1)+toArray().length替代，提前终止，更快
为什么 estimatedDocumentCount() 有时不准？
它读的是集合元数据里的 count 字段，这个值只在后台定期更新（比如执行 compact 或某些维护操作后），中间发生的插入/删除不会实时同步。
- 刚删掉 10 万条文档，
estimatedDocumentCount()可能还显示旧总数 - 高写入场景下，误差可能达数万级；仅适合监控大盘、展示“约 XX 万条”这类无精度要求的场合
- 它和
countDocuments({})结果不一致，不是 bug，是设计使然
真正容易被忽略的点：countDocuments() 的查询对象必须是合法 BSON，空对象 {} 是允许的，但 null 或 undefined 会报错；另外，聚合管道里不能用它——要统计聚合结果数量，得靠 $group 加 $sum: 1 或最后接 $count 阶段。
