deleteMany删不掉文档却没报错，因deletedCount: 0是合法成功响应；常见原因包括过滤条件误用JavaScript语法、ObjectId未封装、正则写法错误、字段名拼错且未启用strictQuery；空条件{}会删光整表，须代码层校验、配置strictQuery及权限管控；清空集合优先用drop()，更高效彻底，除非需保留索引等元信息。
deleteMany 为什么删不掉文档，却没报错？
因为 deletedCount: 0 是合法成功响应，不是错误。MongoDB 认为“条件匹配 0 条”和“匹配 1000 条”一样，都属于正常执行流程。
常见诱因：
- 过滤条件写成 JavaScript 语法，比如用
==或===，而 MongoDB 查询必须用$eq、$gt等操作符 -
ObjectId字符串没包裹成new ObjectId("...")，结果当普通字符串比对，永远不等 - 正则写法错误：Node.js 驱动里不能直接写
/abc/，得用{$regex: "abc"} - 字段名拼错，且驱动没开
strictQuery: true，导致该字段被静默忽略
实操建议：
- 删之前先用
find()跑同一条件，确认能查出目标文档 - 日志里必须记录
result.deletedCount，不能只看acknowledged === true - 在 Mongoose 中启用
strictQuery: true，避免字段名打错却无提示
空条件 {} 会删光整张表，怎么防住？
是的，deleteMany({}) 就是删光当前集合全部文档，且不带任何警告或确认。
线上环境必须加硬校验：
- 代码层：调用前检查 filter 是否为字面量空对象或只含
$where、$expr等高危操作符，直接throw new Error("unsafe deleteMany") - 配置层：Mongoose 连接时设
strictQuery: true；原生驱动可配ignoreUndefined: true防止字段名拼错漏判 - 权限层：给应用账号去掉
dropCollection权限，但保留remove——至少能拦住误执行drop()
别依赖“我不会手抖写错”，要靠机制兜底。
deleteMany 和 drop()，到底该选哪个清空集合？
优先用 drop()，除非你明确需要保留索引、validator、collation 或 TTL 规则。
关键差异：
-
drop()是原子级删除集合文件，毫秒完成，立即释放大部分磁盘空间（WiredTiger 下后续 compact 可进一步清理） -
deleteMany({})是逐条标记删除，不删索引、不释放空间、仍受 oplog 和 write concern 约束，大集合可能卡住写入 -
drop()后集合彻底消失，再次插入会重建索引；deleteMany({})则保留所有元信息
注意：drop() 不可回滚，没有回收站。执行前务必 double-check 集合名，尤其在分片集群中它会自动广播到所有分片。
大批量删除（如百万级）要注意什么？
性能和稳定性风险集中在两点：锁竞争与内存压力。
实操要点：
- 确保过滤字段有索引，否则全表扫描会阻塞其他写入，甚至触发慢查询告警
- 避免在副本集主节点上一次性删太多——从节点同步延迟可能导致“删完立刻查还剩几条”的假象
- 如果必须用
deleteMany（比如要保留 validator），且数据量极大，考虑分批删：deleteMany({ _id: { $lt: ObjectId("...") } })+ 游标推进，每次 limit 1w~5w -
deleteMany不触发 Mongoose 的pre('remove')中间件，业务逻辑依赖钩子的，得手动补调
真正麻烦的不是语法怎么写，而是删完才发现监控指标断崖下跌、下游服务缓存没清、change stream 客户端没处理 drop 事件——这些都得提前对齐。
