composer install变慢主因是vcs/目录（含大体积.git仓库）和系统临时目录（/tmp或%temp%）中堆积损坏zip未被clear-cache清理，需手动删除并禁用cache-vcs。
Composer 本身没有“导出”功能，你实际想解决的，是 composer install 或 composer update 执行慢、卡在 downloading、解压失败或反复重试——这些现象背后，90% 是缓存目录里堆积了损坏 ZIP、过期 Git 克隆、重复元数据或系统临时文件。清理这些“垃圾”，才能真正提速。
为什么 composer install 越来越慢？重点查 vcs/ 和 sys_get_temp_dir()
默认 composer clear-cache 只清 files/（ZIP 包）和 repo/（元数据），但最拖后腿的两个位置它完全不碰：
-
vcs/目录：每个 Git 裸仓库（如laravel/framework）自带完整.git，单个就占 300–800 MB，且 Composer 拉取时会先 clone 再打包，比直接下 ZIP 慢 3–5 倍 -
sys_get_temp_dir()（通常是/tmp或%TEMP%）：composer_*.zip、php*.phar文件堆积在此，clear-cache根本不扫这里，重试时还可能复用损坏的临时包
执行 du -sh $(composer config --global cache-dir)/vcs 和 find $(sys_get_temp_dir()) -name "composer_*.zip" | head -5，如果看到大量输出，就是瓶颈所在。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
群晖 NAS 上 composer clear-cache 卡住或清错位置？绕过命令，直删文件
群晖的 PHP 运行环境特殊：http 用户、admin 用户、Docker 容器各有一套缓存路径，且 clear-cache 默认要交互确认，在无 TTY 的 Task Scheduler 或 Docker 中直接 hang 住。
- 先确认真实用户和路径：
ps aux | grep composer看 USER 列，再用sudo -u http composer config --global cache-dir查准路径 - 别用
clear-cache：直接删vcs/（安全，下次需要自动重建）：sudo -u http rm -rf $(sudo -u http composer config --global cache-dir)/vcs/* - 同步清临时 ZIP：
sudo -u http find /tmp -name "composer_*.zip" -delete 2>/dev/null - 删完加禁用：
sudo -u http composer config --global cache-vcs false，后续全走--prefer-dist，避免再 clone
CI/CD 构建中 composer install 反复失败？删缓存前必须检查锁和权限
自动化环境里手动删缓存风险高，常见报错 Corrupted cache file 或 Permission denied 都源于进程冲突或属主错乱：
- 删前查占用：
lsof +D $(composer config --global cache-dir)（Linux/macOS），有输出就kill对应 PID - 权限修复（别硬加
sudo）：chown -R $USER:$USER $(composer config --global cache-dir) - 加
--no-interaction --dry-run预检：composer clear-cache --no-interaction --dry-run，确认路径没指向 NFS 或只读卷 - 长期方案：在
composer.json加"cache-max-size": "500M"，并设"cache-vcs": false，从源头控体积
真正容易被忽略的是：vcs/ 目录不清理，composer install 就永远快不了；而群晖或 CI 环境里，clear-cache 命令本身大概率失效——得靠 rm -rf 和 cache-vcs false 组合拳才管用。
