updateMany() 是 MongoDB 批量更新主力方法，需谨慎使用 filter 和 update 参数：filter 必须为 BSON 表达式，不可混用 JS 逻辑；多条件应拆分为独立 filter；空 filter {} 会匹配全集，生产环境须先验证；时间范围需用 ISODate()；update 参数支持对象或聚合管道。
updateMany() 是 MongoDB 批量更新的主力方法，但它不是“写一次、改全表”的安全按钮——用错 filter 或 update 结构，轻则漏改、重则误刷整库。
filter 怎么写才真正匹配目标文档
过滤条件必须是 BSON 表达式，不能是 JavaScript 逻辑。常见错误是把 {sex: "男", result: {$gte: 90}} 当成代码分支来用，其实它只是「同时满足两个字段条件」的静态筛选。
- 要更新「男生且分数≥90」和「女生且分数≥60」两类人，
{sex: "男", result: {$gte: 90}}和{sex: "女", result: {$gte: 60}}是两个独立 filter，不能合并进一个对象里 - 空 filter
{}真的会扫全集合，生产环境务必加explain()或先用countDocuments()验证数量 - 时间范围别手写字符串：
birthday: {$gte: ISODate("1990-01-01"), $lt: ISODate("2000-01-01")}，mongosh 里不加ISODate()会被当字符串比较
update 参数传对象还是聚合管道
低版本（
- 简单覆盖字段用
{$set: {status: "active"}} - 按字段值分支赋值，必须用管道：
[{$set: {is_qualified: {$switch: {branches: [...], default: false}}}}]，漏掉外层方括号或写成对象会直接报错Invalid pipeline operator -
$switch的每个case必须是完整 BSON 表达式，{$and: [{sex:"男"}, {result: {$gte: 90}}]}才合法，{sex:"男", result: {$gte: 90}}在管道里无效
options 里哪些选项实际有用
默认选项够日常用，但大集合或特殊场景下几个 key 选项不能忽略：
-
upsert: true慎开——updateMany()开了之后，只要 filter 不匹配任何文档，就会插入一条空文档（只含_id），不是“没匹配就不动” -
collation: {locale: "simple"}对纯英文/数字字段能省掉排序开销，万级以上批量更新建议显式指定 -
hint可强制走某个索引，比如你确定{sex: 1, result: 1}索引最有效，就传{hint: {sex: 1, result: 1}}，避免查询优化器选错 -
arrayFilters只在更新嵌套数组元素时需要，例如{$set: {"comments.$[c].approved": true}}配合arrayFilters: [{c: {author: "admin"}}]
为什么 updateMany() 有时像没生效
不是语法错，而是语义陷阱：
- 更新字段不存在？
$set会新建字段，$inc或$mul则静默跳过——检查目标字段类型是否为数字 - 用了
$rename却发现字段还在？说明原字段名拼错，或目标名已存在（$rename不覆盖） - 返回的
matchedCount和modifiedCount不等？说明有文档匹配但值没变（比如$set设了相同值），这不是 bug，是设计行为 - 没建索引的 filter 字段，小集合看不出问题，上万文档时可能卡住甚至触发慢查询日志
真正麻烦的从来不是语法能不能跑通，而是你是否清楚这次更新到底影响了几条、哪些字段被改了、有没有隐式类型转换在暗处起作用——尤其当 updateMany() 跑在定时任务里，没人盯着输出的时候。
