composer解压强制依赖ziparchive且不可配置，需实测扩展可用性；“no space left”多因临时目录inode耗尽而非磁盘空间不足；cache/vcs/需手动清理或禁用以避免inode爆炸。
Composer默认用ZipArchive解压，不是可选项而是硬依赖
它根本不会“选择”zip还是tar——只要包的dist.type是zip（绝大多数公开包都是），Composer就调用ZipArchive::extractTo()解压。这不是配置开关，是底层行为。你看到日志里Downloading https://.../package-1.2.3.zip，说明流程已锁定zip路径。
常见误判：以为装了ext-zip就万事大吉。错。必须实测：php -r "new ZipArchive();"不报错才算真正可用；php -r "echo ZIPARCHIVE::CHECKSUM_CRC32;"能输出数字，才代表libzip ABI兼容。Docker镜像如php:8.2-cli-alpine默认没zip扩展，得手动装。
-
zlib_decode(): data error多见于PHP 8.2+、WSL或Windows，根源是zlib对ZIP64或数据描述符解析不稳定，不是包损坏 - 禁用zlib输出压缩：
zlib.output_compression = Off（注意是Off，不是0） - 临时绕过：设
COMPOSER_UNZIP=7zip并确保系统有7z命令，比硬扛zlib更稳
临时目录才是“No space left on device”的真凶
报错卡在Downloading阶段，90%不是磁盘块满，而是sys_get_temp_dir()所在分区的inode耗尽。Linux/macOS默认走/tmp，Windows走%TEMP%。Composer解压ZIP、生成autoload、跑脚本全在这儿建临时文件，全是小文件，专吃inode。
先确认路径：php -r "echo sys_get_temp_dir();"；再查真实占用：df -h看空间，df -i看inode——如果IUse%接近100%，哪怕df -h显示剩20GB也照样失败。
- Linux/macOS清理：
find $(php -r "echo sys_get_temp_dir();") -name "composer_*" -o -name "php*.phar" -delete 2>/dev/null - Windows需手动进
$env:TEMP目录，删所有composer_*.zip和php*.phar - 换临时目录应急：
export TMPDIR="/mnt/bigdisk/tmp"（COMPOSER_CACHE_DIR不管解压位置，TMPDIR才管）
cache/files/和cache/vcs/要分开处理
composer clear-cache默认清cache/files/（存.zip/.tar包）和cache/repo/（元数据快照），但cache/vcs/（Git裸仓库）被跳过——每个裸仓库300–800MB、成千上万个文件，是inode杀手。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
想精准瘦身：cache/files/里只删当前所有composer.lock里没引用的版本，比如锁文件只写"version": "2.4.0"，那就删掉monolog-monolog-1.20.0.zip这类旧包；cache/vcs/可以直接全删：rm -rf ~/.composer/cache/vcs/*（下次需要时自动重建，安全）。
- 长期方案：
composer config --global cache.vcs false，强制所有Git包走--prefer-dist，彻底避开裸仓库 - 别碰
cache/repo/packagist.org/——删了首次composer update会卡很久 -
cache-files-maxsize默认300MiB，可调大：composer config --global cache-files-maxsize "500MiB"
post-install-cmd钩子里不能乱删vendor/composer/下的文件
很多人在post-install-cmd里写rm -f vendor/composer/autoload_*.php，结果后续命令直接崩。这些文件是Composer运行必需的，不是“临时产物”。
真正该清理的是构建脚本产生的东西：比如php artisan package:discover生成的bootstrap/cache/packages.php，或前端构建留下的public/build/、node_modules/.cache/。这些跟Composer无关，但占空间、易堆积。
- 跨平台安全写法：用PHP脚本代替
rm/del，避免系统命令差异 - Windows下别用
del /q直接删整个public/build，先if exist public\build rmdir /s /q public\build -
composer dump-autoload后立刻删autoload文件？不行。等整个钩子执行完再处理，否则中断Composer内部状态
临时目录路径、ZipArchive实际可用性、vcs缓存是否被忽略——这三点最容易被当成“清缓存就能解决”，结果反复踩坑。查df -i、实测new ZipArchive()、手动删vcs/，比盲目clear-cache有效得多。
