中断后真正需手动删的是PHP系统临时目录中composer_*.zip等残留文件，而非vendor/或~/.composer/cache/；因Composer解压ZIP时先存至sys_get_temp_dir()（如/tmp或%TEMP%），中断易致其占满inode且clear-cache无法清理。
Composer install 中断后，哪些临时文件真要手动删？
中断后真正需要你动手清理的临时文件，基本只在 PHP 系统临时目录里，不是 vendor/，也不是 ~/.composer/cache/。Composer 下载 ZIP 包时会先解压到 sys_get_temp_dir() 返回的位置（Linux/macOS 通常是 /tmp，Windows 是 %APPDATA%\Local\Temp），生成形如 composer_XXXXXX.zip 或 composer_XXXXXX/ 的临时文件。这些文件不会被 composer clear-cache 清掉，中断后常残留并占满 inode。
验证是否是它惹的祸：df -i 看 inode 使用率是否 100%，再查 ls -lt /tmp | head -20 | grep composer（Linux/macOS）或 dir %TEMP%\composer*（Windows）。找到就删：rm -f /tmp/composer_* 或 del /q %TEMP%\composer*。
为什么删了 vendor 和 lock 还报 “Corrupted zip file”？
因为错误根源不在 vendor，而在缓存 ZIP 文件本身损坏，且 composer.lock 仍锁定旧哈希值——Composer 读到 dist.sha256 就去 ~/.composer/cache/files/ 找对应 ZIP，哪怕你删了整个 vendor/，它仍会尝试复用那个坏包。
- 先定位坏包：看
composer install -v最后一行，比如Failed to extract vendor/symfony/console - 进缓存目录：
composer config --global cache-dir查路径，再进files/子目录 - 只删匹配 ZIP：
rm -f *symfony*console*.zip（Linux/macOS）或 PowerShell 中Remove-Item "$env:APPDATA\Composer\Cache\Files\*console*.zip" -Force - 必须同步删
composer.lock和vendor/，否则哈希锁死问题仍在
CI/CD 或 WSL 环境下最容易忽略的权限陷阱
WSL 用户若把项目放在 /mnt/c/ 下执行 composer install，中断后重试大概率失败——chmod 和 chown 在 Windows 文件系统上是空操作，缓存目录权限实际没改，导致后续写入失败但无明确报错。
Linux/macOS CI 环境常见坑：
-
composer clear-cache后立刻composer install→ 仍走坏缓存，因 lock 文件未更新 - Docker 构建中用了旧版
composer.lock（含 packagist.org 源），即使换镜像源也拉不到包 - 未设
COMPOSER_HTTP_TIMEOUT，超时中断后残留半截 ZIP，下次还读它
对策：CI 脚本开头加 rm -rf $(composer config --global cache-dir)/files/*，再跑 composer install --no-cache --force-checksums。
别信“删 vendor 就完事”，autoload.php 空文件才是静默故障源
中断最隐蔽的后果，是 vendor/autoload.php 文件存在但内容为空，或只有几行注释。PHP 不报错，但所有类加载全挂——你跑 php -m 看 extension 没问题，composer show 显示包都在，就是 Class not found。
检查方法很简单：head -n 5 vendor/autoload.php。如果输出是空或只有 <?php 没后续，说明生成中断了。
此时不能只删 autoload.php 再 dump，得先确保 vendor/ 和 composer.lock 都干净，再跑：
-
composer install --no-scripts --no-autoloader（跳过易失败步骤） -
composer dump-autoload -o（强制重建，-o 关键）
这一步漏掉，90% 的“看似装好了却跑不起来”问题都还在。
