Composer clear-cache 在 CI/CD 中常卡住，因其默认等待交互确认，而 GitHub Actions、GitLab CI 等无 TTY 环境无法输入；必须加 --no-interaction，建议先用 --dry-run 验证路径，若仍卡住则用 lsof（Linux/macOS）或 handle.exe（Windows）查占用进程。
composer clear-cache 为什么在 CI/CD 里经常卡住
因为默认会等待交互确认，而 GitHub Actions、GitLab CI 等无终端环境根本没法输入 yes。结果就是命令挂住、超时失败、构建中断。
- 必须加
--no-interaction：这是硬性要求，否则无法自动化执行 - 建议先加
--dry-run：输出将清理的路径，确认它指向的是本地磁盘而非 NFS 挂载点（比如/mnt/cache/composer） - 如果仍卡住，说明有其他进程正占用缓存目录：Linux/macOS 用
lsof +D $(composer config --global cache-dir)查；Windows 用handle.exe -p php.exe（需 Sysinternals 工具）
COMPOSER_CACHE_DIR 环境变量改路径后，clear-cache 还管用吗
管用，但只清你设的那个路径——composer clear-cache 完全遵循 composer config --global cache-dir 输出的位置，不认默认路径，也不扫其他位置。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 设置方式：
export COMPOSER_CACHE_DIR="/data/composer-cache"（Linux/macOS）或set COMPOSER_CACHE_DIR=C:\cache\composer（Windows CMD） - 验证是否生效：
composer config --global cache-dir必须返回新路径，否则clear-cache仍清旧位置 - CI 构建机上常见坑：多个 job 共享同一缓存目录但没加锁，导致
clear-cache和install并发冲突，报Corrupted cache file
怎么让 clear-cache 真正释放几百 MB 空间
关键不是跑命令，而是删对地方：clear-cache 默认跳过 vcs/ 目录，而它才是空间和 inode 的双料杀手——单个 Git 裸仓库就占 300–800 MB，且含上万小文件。
- 先确认真实占用：
du -sh $(composer config --global cache-dir)/vcs（Linux/macOS），Windows 对应%APPDATA%\Composer\Cache\vcs右键属性 - 手动清
vcs/：rm -rf ~/.composer/cache/vcs/（注意尾部斜杠）或 Windows 的rd /s /q "%APPDATA%\Composer\Cache\vcs" - 一劳永逸：运行
composer config --global cache-vcs false，后续所有包强制走--prefer-dist，不再克隆 Git 仓库
清完缓存，为什么 vendor/ 还是那么大
composer clear-cache 根本不碰 vendor/ 目录——那是项目依赖安装结果，不是缓存。中等 Laravel/ThinkPHP 项目 vendor/ 占 300–800 MB 是常态，跟缓存大小无关。
- 想省空间，得另起炉灶：
composer install --no-dev --optimize-autoloader可砍掉测试工具和冗余 autoload 映射 -
vendor/里真正吃空间的是大资产包（如laravel/ui、symfony/css-selector），可按需替换为轻量方案 - CI 构建机更推荐策略：每次构建前
rm -rf vendor+composer install --no-cache，避免复用旧缓存引入污染
vcs/ 目录和 COMPOSER_CACHE_DIR 的实际生效路径——前者不手动删，clear-cache 就等于只擦了桌面灰尘；后者没验证就设，可能清了个寂寞。 
