updateMany()无法直接更新数组内嵌对象，需用$[]或arrayFilters；嵌套多条件更新须用聚合管道+$map；注意字段大小写、null处理及索引优化。
updateMany() 不能直接更新数组内嵌对象，得用 $[] 或 arrayFilters
想批量更新数组里满足条件的元素，比如把 tags 数组中所有 status: "pending" 的对象改成 status: "done"，updateMany() 默认只匹配外层文档，不会自动遍历数组。直接写 {$set: {"tags.$.status": "done"}} 只改第一个匹配项；不加定位符则报错 Path not found。
正确做法是用 $[]（全量数组元素）或 arrayFilters（带条件筛选）：
-
$[]：无条件更新整个数组每个元素，例如{$set: {"tags.$[].status": "done"}} -
arrayFilters：指定条件，只更新匹配的数组项，例如{arrayFilters: [{ "tag.status": "pending" }]}配合{$set: {"tags.$[tag].status": "done"}} - 字段名必须和
arrayFilters中一致，"tag.status"里的tag是别名，不是原始字段名 -
$[tag]中的tag必须在arrayFilters里声明，漏掉就报错Invalid array filter
嵌套数组+多条件更新，必须用聚合管道 + $map
当数组里每个对象还有子数组（比如 items 里含 sub_list），且要按 category 和 item 双重条件追加值，$set 和 arrayFilters 就不够用了。这时候只能上聚合管道——MongoDB 4.2+ 支持把整个 update 参数写成数组。
关键点：
- 整个 update 参数必须是数组，例如
[{$set: {...}}]，写成对象会忽略管道逻辑 - 用
$map遍历外层数组，内部用$cond或$switch判断是否命中目标item - 对命中项用
$mergeObjects合并新字段，避免覆盖原有结构 - 所有数组访问都要包一层
$ifNull，否则遇到空数组或缺失字段直接失败 - 别忘了在
filter里只匹配外层文档，比如{category: "A"}，别写{"list.item": 1}，否则触发数组索引匹配歧义
更新后查不到？检查字段路径大小写和 null 值处理
明明语法跑通，但执行完发现数据没变，常见原因是字段路径写错或值为 null 导致表达式短路。MongoDB 字段名严格区分大小写：Tags 和 tags 是两个字段；数组字段若本身为 null 或不存在，"tags.0.name" 这类路径会静默失败。
安全写法：
- 用
$ifNull: ["$tags", []]把可能为空的字段转成空数组，再进$map - 字段名统一小写，避免和应用层传入的驼峰命名冲突
- 先用
find()确认目标文档结构，尤其注意数组是否真的存在、是否为空 - 测试时加
limit(1)和projection，只看一条结果，避免被海量数据干扰判断
性能卡顿？索引和分批是硬门槛
批量更新数组内对象，慢的从来不是语法，而是锁和扫描。WiredTiger 引擎下虽是文档级锁，但上万文档逐个更新数组字段，仍会明显拖慢读请求。
必须做的几件事：
- 给 filter 用到的外层字段建复合索引，例如
db.collection.createIndex({category: 1, "tags.status": 1}) - 字符串字段参与比较时（如
tags.name），加{collation: {locale: "simple"}}避免排序开销 - 单次更新超过 5 万文档，手动按
_id范围分批，比如{_id: {$gt: ObjectId("..."), $lt: ObjectId("...")}} - 别在业务高峰期跑全集合更新，尤其是
updateMany({}, ...)这种没 filter 的操作
真正容易被绕开的，是“要不要动全量”这个判断——如果只是新增了几条记录，通常只需更新新增部分，而不是重刷整个集合。
