答案是临时目录sys_get_temp_dir()堆积导致I/O瓶颈和inode耗尽；镜像配置不影响该路径，其默认为/tmp或Windows临时文件夹，若落在低速盘、被定时清理或未挂载SSD，解压时会因小文件密集操作卡在“Extracting archive”，需迁移路径并禁用cache.vcs。
中文镜像配置本身不改变临时文件存储位置，但配错或未清理旧缓存会导致 sys_get_temp_dir() 下的临时 ZIP 解压目录反复堆积、inode 耗尽——这才是运行时卡在 “Extracting archive” 的真正原因。
为什么换镜像后 sys_get_temp_dir() 还在爆满
镜像只影响包元数据和 ZIP 包下载地址，不影响 Composer 解压时用的临时路径。默认使用 PHP 的 sys_get_temp_dir()（通常是 /tmp 或 C:\Users\XXX\AppData\Local\Temp），而该目录常被忽略：某些 Linux 发行版会定时清空 /tmp，导致每次 install 都重建临时解压目录；Windows 上杀毒软件可能锁定临时文件；Docker 容器里若没挂载 /tmp 到 SSD，I/O 延迟直接拉高 20 倍。
- 查当前临时目录：
php -r "echo sys_get_temp_dir();" - 确认是否落在低速盘：
df -h $(php -r "echo sys_get_temp_dir();") - 临时改路径测试：
COMPOSER_TEMP_DIR=/mnt/ssd/tmp composer install
cache.vcs 禁用比镜像配置更能减少临时文件压力
即使用了阿里云分片镜像，只要 cache.vcs 开着，Composer 就会在 sys_get_temp_dir() 下为每个 Git 克隆创建临时工作区（含 .git + 数万个小文件），而禁用后全部走 ZIP 流程，临时目录只存单个 ZIP + 一次解压，体积下降 90%+。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 禁用命令：
composer config --global cache.vcs false - 手动清残留：
rm -rf $(php -r "echo sys_get_temp_dir();")/composer_* - 验证生效：执行
composer update monolog/monolog -v，日志中不再出现Cloning into '/tmp/composer_xxx'
镜像配置错误会让临时文件“白解一次再失败”
当 repo.packagist 配错（比如 URL 少了末尾 / 或写成 repos.packagist），Composer 会 fallback 到官方源，但已把 ZIP 下到临时目录，接着因 404 或 TLS 错误中断，留下残缺的 composer_*.zip 和空目录——这些文件不会自动清理，composer clear-cache 也管不到 sys_get_temp_dir()。
- 排查方法：
ls -lt $(php -r "echo sys_get_temp_dir();")/composer_*，看是否有大量时间戳接近的残留文件 - 安全清理脚本：
find $(php -r "echo sys_get_temp_dir();") -name "composer_*" -mmin +5 -delete（仅删 5 分钟前的） - 根本解法：用
composer config -g repo.packagist确认输出是完整 JSON，且含正确 URL；否则重跑配置命令
临时目录不是“次要路径”，它是 Composer 所有解压、校验、安装动作的必经之地；镜像再快，解压卡在 /tmp 的机械盘上，就等于高速路修到一半变成土路。别只盯着 cache-dir，先盯住 sys_get_temp_dir() 落在哪块物理盘上。
