MongoDB 4.4中background: true已废弃，因默认启用同步建索引机制，仅在元数据注册和指针切换时加短暂集合锁，读写基本无感；其存在仅为兼容，实际行为与不设该参数一致。
4.4 版本里，background: true 和默认前台建索引在行为上已无本质区别，但语义和兼容性仍有关键差异 —— 不再是“要不要阻塞”的选择，而是“要不要启用同步建索引机制”的开关。
为什么 background: true 在 4.4+ 中几乎没用了
MongoDB 4.2 起就改了锁机制：索引构建只在开始和结束瞬间加集合级排他锁，中间过程全程允许读写。到了 4.4，这个行为被进一步固化为默认策略，叫“同步建索引（Simultaneous Indexing）”。它不是后台模式，也不是传统前台模式，而是一种新范式：
-
background: true在 4.4+ 中只是个向后兼容的 flag，实际执行逻辑和不设它一样 —— 都走同步建索引流程 - 真正决定是否“可中断续建”的，是
fCV（featureCompatibilityVersion）是否设为"5.0"，而不是background参数 - 如果你在 4.4 上显式写了
{ background: true }，MongoDB 会忽略它，日志里可能还报 warning：“background option is deprecated”
createIndex() 在 4.4 中的实际行为取决于 fCV
fCV 控制的是功能启用开关，不是版本号。即使你用的是 4.4 二进制，只要 fCV 还是 "4.4"，就只能用同步建索引（不可恢复）；升级到 "5.0" 后，新创建的索引才支持中断后从检查点续建。
- 确认当前 fCV：
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 }) - 升级 fCV 前必须确保所有节点都已升级到 5.0+，否则复制集会拒绝写入
-
fCV: "5.0"对已有索引无效，只影响新createIndex()调用 - 即使 fCV 是
"5.0"，也不代表所有索引都能恢复 —— 只有那些在该 fCV 下新建的索引才具备可恢复能力
前台建索引（不设 background）在 4.4+ 还会锁库吗？
不会。这是和 3.x/4.0 的最大区别。
- 3.6 及更早：前台建索引 = 库级排他锁，整个数据库卡死
- 4.2+：前台建索引 = 仅集合级短暂排他锁（毫秒级），其余时间用意向锁（IX），不影响其他集合读写
- 4.4+：前台行为完全继承 4.2 的优化，且默认启用同步建索引，所以“前台”只是语义上表示“不指定 background”，实际效果和加了
background: true几乎一致 - 唯一可见差异：前台建索引在元数据提交阶段略快一点（少了后台任务调度开销），但对亿级数据来说，差别通常小于 1%
真正该关心的不是前台/后台，而是这三件事
在 4.4 环境下纠结 background 已意义不大，重点应转向更实际的约束：
- 内存是否够？WiredTiger 缓存要 ≥ 索引预估大小 × 1.5，否则会频繁刷盘拖慢进度
- 磁盘 I/O 是否饱和？索引构建是顺序写密集型操作，SSD 比 HDD 快 3–5 倍
- 是否用了
partialFilterExpression或sparse: true？这些能大幅减少索引体积和构建时间，比纠结前台后台实在得多
容易被忽略的一点：4.4 的同步建索引虽然允许并发写入，但写操作若触发唯一约束冲突（比如往唯一索引字段插重复值），会直接失败并中止整个索引构建 —— 这不是 bug，是设计使然。上线前务必清理脏数据或临时禁用相关写逻辑。
