Composer install卡在Extracting archive阶段本质是I/O瓶颈，源于ZIP解压时高频小文件系统调用叠加低速磁盘或虚拟文件系统桥接层延迟，需优先排查await、%util、inode占用及cache-dir挂载位置。
为什么composer install卡在Extracting archive阶段
不是网络慢，也不是CPU不够，而是解压 ZIP 包时密集触发 stat()、open()、read() 等小文件系统调用，遇上低速磁盘或虚拟文件系统桥接层（如 WSL2 的 /mnt/c、CI 中的宿主机挂载卷），单次调用延迟从 0.1ms 涨到 20ms，几百个包叠加后直接卡死。
典型现象包括：file_put_contents(): failed to open stream（实际是 I/O 超时伪报错）、No space left on device（但 df -h 显示空间充足）、-vvv 日志长时间停在 “Extracting archive” 或 “Writing lock file”。
- 确认是否为 I/O 问题：运行
composer config --global cache-dir，再结合iostat -x 1观察%util和await；若await > 20ms且%util接近 100%，基本锁定 - 不要只看磁盘剩余空间，更要查 inode 使用率：
df -i——cache/vcs/目录下 Git 裸仓库动辄数万小文件，极易耗尽 inode - WSL2 用户务必避开
/mnt/c路径，哪怕 SSD 也扛不住跨系统文件桥接
cache-dir 落在哪块盘上，比镜像源还关键
Composer 缓存目录（cache-dir）默认落在用户主目录，而很多 CI runner 或 WSL2 环境的 /home/xxx 实际挂载在低速存储（如网络盘、加密卷、Windows NTFS 分区），导致元数据（packages.json）加载慢、ZIP 解压刷盘频繁，冷热数据互相干扰。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 强制迁移到本地 SSD：
composer config --global cache-dir /mnt/ssd/composer-cache - Linux CI runner 可用内存盘：
sudo mount -t tmpfs -o size=2G tmpfs /mnt/ramdisk && composer config --global cache-dir /mnt/ramdisk/composer-cache - 禁用
cache.vcs（非必需）：composer config --global cache.vcs false，可降 I/O 压力 70%+，因cache/vcs/是 inode 和随机读双杀器 - 改完必须执行
composer clear-cache—— 旧缓存不会自动迁移，新路径要清完才真正启用
预读取策略没用，真正该调的是 IO 调度器和挂载方式
Linux 默认的 cfq 或 mq-deadline 调度器对 Composer 这种成千上万小文件的随机读场景响应极差。所谓“预读取”（readahead）在 ZIP 解压这种不可预测的访问模式下基本无效，反而浪费带宽。
- 查当前调度器：
cat /sys/block/sdX/queue/scheduler（把sdX换成你cache-dir所在盘的实际设备名，如sdb） - SSD/NVMe 盘用
noop或kyber：echo kyber > /sys/block/sdX/queue/scheduler - HDD 或虚拟机 overlay2 分区用
deadline，减少请求饿死 - 比调度器更致命的是挂载方式：
-v $(pwd)/vendor:/app/vendor这类宿主机挂载会让每次stat()都穿桥接层；开发中应改用命名卷，CI 中应在容器内生成vendor/后导出，而非挂载
CI 构建里最容易被忽略的三个硬伤
CI 环境下 composer install 慢，90% 不是配置问题，而是平台默认行为踩了 I/O 红线。
-
cache:配置若包含vendor/，会反复同步小文件，放大 I/O 压力；应只缓存~/.composer/cache -
/tmp不是安全缓存位置：AWS CodeBuild、某些 GitHub Actions runner 会定时清空/tmp，导致缓存反复重建 -
parallel-downloads设太高反坏事：尤其在/dev/shm空间不足时，多个进程争抢临时文件句柄，file_put_contents错误会掩盖真实 I/O 瓶颈
真正拖慢 Composer 的，从来不是某一行配置，而是磁盘调度、挂载方式、缓存路径三者叠加下的 I/O 雪崩。调完调度器还卡？先 df -i 和 mount | grep vendor。（2026年6月24日）
