换源后clear-cache才真正有效，因镜像切换使元数据来源统一，清除旧packagist.org残留zip和repo快照；必须用完整命令composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，漏参数或斜杠则静默失效。
配中文镜像本身不省空间，但它是后续精准清理缓存的必要前提——否则 composer clear-cache 会反复从 packagist.org 拉元数据，导致 cache/repo/ 和 cache/files/ 积累大量无效校验文件，且无法被自动 GC。
为什么换源后 composer clear-cache 才真正有效
没换源前，Composer 默认从 packagist.org 获取 packages.json，即使你本地有缓存，也会频繁回源校验哈希；一旦切到阿里云镜像（如 https://mirrors.aliyun.com/composer/），元数据结构一致但响应更快、更稳定，clear-cache 就能真正清掉旧源残留的失效 ZIP 和过期 repo 快照。
- 必须用完整命令：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，漏掉中间的composer或末尾/都会静默失效 - 验证是否生效：
composer config -g repo.packagist输出应为纯 URL 字符串，不含packagist.org - 换源后立刻执行
composer clear-cache，否则旧缓存仍会干扰后续安装逻辑
cache/vcs/ 是磁盘和 inode 双杀，禁用比清理更关键
这个目录默认不参与 clear-cache，单个 Git 裸仓库就占 300–800 MB，含上万小文件，是 No space left on device 的高频原因。尤其当 df -i 显示 inode Use% ≥ 95% 时，vcs/ 就是头号目标。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先禁用：
composer config --global cache.vcs false - 再手动删残留：
rm -rf ~/.composer/cache/vcs/（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 副作用仅限首次
composer update稍慢（改走--prefer-dist），但彻底规避裸仓库再生
把 cache-dir 挪到大分区，避免反复爆满
默认缓存路径常落在 C 盘（Windows）或 /home（Linux），而真正空闲的是 D 盘或 /mnt/data。清缓存只是擦边球，换位置才是治本。
- 查当前路径：
composer config --global cache-dir - 设新路径：
composer config --global cache-dir "/mnt/data/composer-cache"（Linux/macOS） - 必须验证：目标目录存在、可写、非 NFS 挂载点，否则解压 ZIP 时会报
failed to open stream: Permission denied
临时目录 sys_get_temp_dir() 是隐形炸弹，得一起管
Composer 解压 ZIP、生成 autoload、跑脚本时全往这儿塞文件，默认是 /tmp（Linux/macOS）或 %TEMP%（Windows）。这些 composer_*.zip 文件最难察觉，却最容易耗尽 inode。
- 查真实路径：
php -r "echo sys_get_temp_dir();" - Linux/macOS 清理：
find $(php -r "echo sys_get_temp_dir();") -name "composer_*" -delete 2>/dev/null - 长期方案：启动前设环境变量，比如
TMPDIR="/mnt/data/tmp" php composer install
真正卡住的不是镜像地址，而是 vcs/ 和系统临时目录的组合拳；哪怕你每天 clear-cache，只要这两处还在默默生成上万小文件，No space left on device 就永远在等你。
