mongodb 4.2+ 彻底移除 foreground 模式，因索引构建已重写为默认启用且不可关闭的 hybrid index build；它仅在起止瞬间加排他锁，中间全程并发读写，旧 foreground 逻辑代码已被剥离。
因为 foreground 模式在 4.2+ 已被移除，不是“废弃”，而是彻底不存在了——你执行 createIndex() 时根本不会走前台路径，无论是否加 background: true。
为什么 4.2+ 不再有 foreground 创建索引这回事
4.2 版本起，MongoDB 把索引构建逻辑重写为 Hybrid Index Build，默认启用，且不可关闭。它只在开始和结束两个极短时间点对集合加排他锁（X lock），用于保护元数据变更；中间阶段全程使用意向锁（IX/IS）并配合 side-write table + oplog 回放，允许读写并发。所谓 “foreground” 是旧版全库阻塞模式，与当前机制不兼容，代码层面已被剥离。
常见误解是以为加了 background: false 就能切回前台——实际会忽略该参数，仍走 Hybrid 流程；而显式写 background: true 反而会禁用 Hybrid，强制降级到 4.0 时代的 background 子进程老路径（已标记 deprecated）。
加 background: true 反而更危险
这个选项在 4.2+ 的真实作用是：绕过 Hybrid 构建，退回到 fork 子进程、全表扫描、持续持有 IX 锁的老方式。性能更差，且可能拖慢主节点复制延迟。
- 它会让构建过程无法利用 snapshot + oplog 增量同步能力
- 从节点回放 oplog 时，若遇到该索引构建的中间状态，容易卡住
- 在分片集群中，
background: true可能导致不同分片构建进度严重不一致 - 错误示例：
db.coll.createIndex({a:1}, {background: true})—— 这条命令在 4.2+ 实际效果比不加参数还差
如何确认当前索引正在用 Hybrid 方式构建
没有直接命令显示“是否 Hybrid”，但可通过以下现象交叉验证：
- 执行
createIndex()后立刻查db.currentOp({secs_running: {$gt: 0}})，看不到长时间运行的 indexBuild 操作（旧 background 模式会卡在这里） - 观察
db.serverStatus().metrics.record.moves和db.serverStatus().metrics.getLastError.wtime，Hybrid 构建期间写入延迟无明显尖峰 - 在构建过程中对同一集合执行
find()或updateOne()能正常返回，不报InterruptedAtShutdown或锁等待超时 - 查看日志里是否有类似
Index build: building index using hybrid mode的记录（部分企业版或 debug 日志级别下可见）
升级到 4.4+ 后还要注意什么
4.4 解决了 4.2 遗留的几个关键问题，但 Hybrid 本身逻辑未变。真正要盯住的是并发操作冲突：
- 索引构建中执行
dropIndexes仍可能阻塞 oplog 回放，尤其在 4.2/4.3 分片集群中 -
compact命令在 4.4+ 不再阻塞读写，但它和索引构建共享底层存储层资源，高负载下仍可能相互影响 - 唯一索引构建失败时，错误不会立即抛出，而是先记入 constraint violation table，等构建完成才汇总报错——这意味着你要等几分钟才能知道字段重复
- 如果集合有大量 TTL 索引文档正在过期，Hybrid 构建可能因频繁 side-write 写入而变慢，这不是 bug，是设计使然
Hybrid 构建不是“完全无感”，它的安全边界在于“短暂元数据锁 + 异步数据填充”。真正容易被忽略的是：它把失败时机往后推了，也把资源竞争从“锁”转移到了“内存与磁盘带宽”上。
