updatemany()必须正确使用bson查询表达式作为filter（如{sex:"男",result:{$gte:90}}），不可用javascript语法；update参数支持普通对象（如{$set:{}}）或4.2+聚合管道数组（如[{$set:{is_qualified:{$switch:{...}}}}]），二者不可混用。
能，用 updateMany() 就行，但必须写对 filter 和 update 参数——错一个括号或少个大括号，就可能全表误更新。
filter 怎么写才真正匹配目标文档
filter 是 BSON 查询表达式，不是 JavaScript 逻辑语句。写成 {sex: "男", result: {$gte: 90}} 没问题；但写成 if (doc.sex === "男") {...} 会直接报错 ReferenceError: doc is not defined。
- 多个条件要用对象嵌套，比如“女生且分数 ≥60”得写成
{sex: "女", result: {$gte: 60}}，不能用&&连接 - 字段名区分大小写，
Sex和sex是两个不同字段 - 空 filter（
{}）会匹配全部文档，生产环境务必先用countDocuments()验证数量：db.students.countDocuments({sex: "男", result: {$lt: 90}})
updateMany() 的 update 参数到底能传什么
它接受两种形式：普通更新对象（如 {$set: {...}}），或聚合管道数组（MongoDB 4.2+ 支持）。别把两者混用。
- 简单统一赋值：直接用
{$set: {status: "processed"}} - 按字段值分支更新（比如男生 ≥90、女生 ≥60 才设
is_qualified: true）：必须用聚合管道，且整个 update 参数得是数组：[{$set: {is_qualified: {$switch: {...}}}}] - 低版本 MongoDB（updateMany() 调用，分别处理男/女逻辑
- 别漏掉方括号——
updateMany({}, {$set: {...}})是对象，updateMany({}, [{$set: {...}}])才是管道
为什么 updateMany() 有时跑得慢甚至卡住
它本身不慢，慢在没索引或锁竞争。WiredTiger 引擎下是文档级锁，但上万文档连续更新仍会明显拖慢读请求。
- 确保 filter 中用到的字段有索引，例如
db.students.createIndex({sex: 1, result: 1}) - 字符串字段参与比较时（如
sex: "男"），加{collation: {locale: "simple"}}可避免排序开销 - 单次更新超过 10 万文档，建议手动分批，比如按
_id范围切片：{_id: {$gt: ObjectId("..."), $lt: ObjectId("...")}} - 别在高峰期执行全集合更新，尤其没加 filter 的
updateMany({}, {...})
真正容易被忽略的不是语法细节，而是「要不要全量重算」这个判断——如果只是新增了几条数据，通常只该更新新数据或变更部分，而不是跑一遍 updateMany({}, [...])。后者一旦出错，回滚成本远高于增量修正。
