前台索引必然卡顿，因其默认获取全局与集合级写锁，阻塞所有读写操作；background: true仅间歇释放锁，不减少CPU、内存及磁盘I/O消耗，4.2+ WiredTiger下仍存在资源竞争，高并发时易触发WT_CACHE_FULL或中断重试。
MongoDB 4.2取消background参数后构建仍会卡顿，是因为前台索引（默认行为）会强制获取全局写锁与集合级写锁，所有读写操作必须排队等待，哪怕只对10万文档的集合建一个单字段索引，接口超时、currentOp显示waitingForLock、副本延迟陡增都会立刻出现。
前台索引为何必然卡顿
第一步：执行db.collection.createIndex({status: 1})不带任何options时，MongoDB自动启用foreground模式。
第二步：该模式下引擎立即申请Global + Collection两级写锁，锁持有期间——无论命令行是否已返回——所有新进写入请求全部阻塞，读请求若需一致性快照也会被挂起。
第三步：WiredTiger在构建过程中持续刷盘，磁盘I/O队列迅速堆积，尤其当磁盘为HDD时，I/O wait飙升至90%以上，进一步拖慢锁释放节奏。
注意：即使命令行瞬间返回，也不代表索引建完；锁会一直持有着，直到排序、写入、校验全部完成。这对生产环境是硬性中断。
background: true为何不是解药
方法一：加{ background: true }只是让构建过程在后台线程间歇运行，它周期性释放锁允许读写继续，但【不降低资源消耗总量】，CPU、内存、磁盘带宽照常被大量占用。
方法二：在4.2+ WiredTiger引擎下，background: true仅避免阻塞其他索引构建任务，对普通写操作仍存在I/O与内存竞争，高并发插入场景下极易触发WT_CACHE_FULL日志告警。
方法三：后台构建可能反复重试——如果集合正被高频写入，WiredTiger缓存来不及腾出空间排序，就会中断当前批次，日志里出现index build failed: interrupted，而db.currentOp()根本查不到该任务。
真正卡顿的隐藏瓶颈
检查mongod日志，若出现slow journal commit或WT_CACHE_FULL提示，说明磁盘写入或内存已成死结。
运行db.serverStatus().storageEngine.name确认引擎，若返回wiredTiger，则background: true不等于“完全不干扰业务”。
【磁盘I/O能力不足是头号杀手】：HDD上建索引比SSD慢5–10倍；若keysExamined远大于docsExamined（比如扫描5万文档只返回25条），说明索引设计低效，但构建过程照旧吃满I/O。
WiredTiger缓存设置过小（wiredTigerCacheSizeGB）会导致构建时频繁swap，进程直接卡死；vm.swappiness值过高会加剧无谓换页，进一步压垮内存响应。
