Composer install在机械硬盘或远程挂载卷上超时主因是解压阶段大量小文件写入导致磁盘I/O饱和，而非网络慢；默认ZIP解压产生数千PHP文件，每个file_put_contents()卡在磁盘队列，触发process-timeout；Docker、WSL2、NAS等场景I/O延迟可达500ms+/op。
为什么composer install在机械硬盘或远程挂载卷上会超时
不是网络慢，是解压阶段大量小文件写入触发了磁盘 I/O 饱和。Composer 默认把 ZIP 包解压成数千个 PHP 文件，每个 file_put_contents() 调用都卡在磁盘队列里，process-timeout 很快就炸。尤其在 Docker 挂载 vendor/、Windows WSL2 共享目录、NAS 挂载点等场景下，I/O 延迟可飙到 500ms+/op，比网络还拖后腿。
--prefer-dist 是必须项，但还不够
它避免 Git clone，改走 ZIP 下载，减少 CPU 和网络开销，但没解决解压本身对磁盘的冲击。真正要控速，得从解压环节下手——而 Composer 不提供解压限速参数。可行路径只有两个：
- 换用
--prefer-source+--no-scripts：跳过 ZIP 解压，改走git clone --depth=1，把 I/O 压力转成内存+网络缓冲，对低带宽磁盘更友好（前提是目标包有 Git 仓库且你信任其代码） - 手动拆包 +
cp -r替代解压：先用curl -L下 ZIP 到临时位置，用系统unzip -q -o加-P（如需密码）或tar --delay-directory-restore控制解压节奏，再mv进vendor/—— 这绕过了 Composer 的解压逻辑，完全可控
用 strace 定位真实瓶颈点
别猜，直接看哪类系统调用卡住：
strace -e trace=openat,write,fsync,mkdir -f -p $(pgrep -f "composer install") 2>&1 | grep -E "(openat|write|fsync)"
如果高频出现 fsync 或 write 返回 EAGAIN，说明磁盘已满负荷；如果 openat 大量阻塞，大概率是文件句柄或 inode 耗尽（尤其在 NFS 上）。此时加 --no-dev 减少包数量、删掉 vendor/ 后重试，比调 Composer 参数更有效。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
缓存目录必须迁离慢盘
composer config -g cache-dir 默认指向 ~/.composer/cache，若家目录在机械盘或远程挂载点，每次下载都会反复刷盘。必须显式移到 SSD 或 /tmp：
mkdir -p /tmp/composer-cache<br>composer config -g cache-dir /tmp/composer-cache
注意：/tmp 若是 tmpfs，需确认大小（df -h /tmp），否则解压大 ZIP 时可能报 No space left on device——这不是磁盘满，是内存满。
真正卡住的地方往往不是下载，而是解压后立刻触发的 autoload classmap 扫描。哪怕你关了 --optimize-autoloader，Composer 仍会在安装末尾扫一遍 vendor/ 下所有 .php 文件。这个动作无法跳过，只能靠提前清理无关目录（比如手动删掉 vendor/*/tests）来减负。
