并发安装卡在“extracting archive”是本地文件系统i/o瓶颈，因解压阶段密集调用stat/mkdir/file_put_contents等系统调用，在macos/windows/ci挂载卷上单次延迟达5–20ms，数百包叠加导致秒级阻塞。
并发安装卡在“Extracting archive”不是网络慢，是本地文件系统扛不住高频小文件操作——尤其在 macOS/Windows/CI 挂载卷上，stat/mkdir/file_put_contents 调用延迟被放大成秒级阻塞。
为什么composer install并发时磁盘 I/O 会崩
Composer 并发下载 ZIP 后，并不直接写入 vendor/，而是先解压到临时目录再移动。这个“解压”阶段会密集调用：stat()、mkdir()、file_put_contents()、openat()。每包平均触发几十次系统调用，几百个包叠加后，I/O 队列直接堆积。
- macOS APFS 或 Windows NTFS 上，单次
stat()延迟常达 5–20ms（Linux ext4 下通常 - CI 中挂载宿主机
vendor/（如-v $(pwd)/vendor:/app/vendor）会引入文件系统桥接层，strace可见大量clock_nanosleep等待 -
No space left on device报错但df -h显示空间充足？大概率是 inode 耗尽（df -i查），尤其cache/vcs/下 Git 裸仓库生成海量小文件
必须改的三个路径配置
缓存、临时目录、vendor 三者若落在同一低速分区（如 macOS 的 /Users/xxx、WSL2 的 /mnt/c、CI runner 的 /home/runner），I/O 争抢会雪上加霜。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查当前缓存位置：
composer config -g cache-dir；若指向网络盘、加密卷或 NTFS 分区，立刻迁移 - 迁移到 SSD：
composer config -g cache-dir /mnt/ssd/composer-cache（确保目录可写且不在 overlay2 或 NFS 上） - CI 中用 tmpfs（Linux）：
sudo mount -t tmpfs -o size=2G tmpfs /mnt/ramdisk && composer config -g cache-dir /mnt/ramdisk/composer-cache - 禁用
cache.vcs（非必需）：composer config -g cache.vcs false，可降 I/O 压力 70%+，因cache/vcs/是 inode 和随机读双杀器 - 改完必须执行：
composer clear-cache——旧缓存不会自动迁移，新路径要清完才真正启用
--no-autoloader --no-scripts 不是可选，是必加项
并发下载快了，但 Generating autoload files 和 post-install-cmd 仍是单线程重负载。一个含 200+ 包的项目，这部分可占总耗时 35% 以上，且完全不受益于任何并发参数。
- CI 构建必须加：
composer install --no-autoloader --no-scripts --no-plugins - 后续补 autoload：
composer dump-autoload --optimize --classmap-authoritative（注意：不是dump-autoload -o，后者在 Composer 2.1+ 中已降级为仅重写静态映射） -
--no-dev不等于跳过所有 dev 包：若主依赖间接引入了phpunit等，它仍会被拉下来。先跑composer show --tree确认依赖树，再针对性排除
挂载陷阱：CI 中 vendor 目录绝不能实时挂载
GitHub Actions/GitLab CI 常见错误是把 vendor/ 直接挂载进容器，导致宿主机与容器间文件操作桥接开销极大。解压几百个包时，openat 和 write 调用排队堆积，strace 可见大量 clock_nanosleep 等待。
- 正确做法：用命名卷（Docker）：
-v composer-vendor:/app/vendor，或纯容器内生成 +rsync -av --delete --exclude='.git' vendor/ $CI_PROJECT_DIR/vendor/ - 绝对避免：
cp -r或tar -cf在挂载点上操作——它们会触发全量stat扫描 - Windows 主机用户：必须将项目路径加入 Windows Defender 排除列表（
Set-MpPreference -ExclusionPath "D:\myproject"），否则解压每个 ZIP 内文件都会触发 AV 扫描
真正卡住的地方，从来不在网络层，而在你没意识到的文件系统桥接、临时目录挂载位置、以及 autoload 生成时对整个 vendor/ 的无差别扫描——这些环节一旦落在慢盘或虚拟文件系统上，毫秒级延迟就会被指数级放大。
