“Corrupted zip file”错误需删除损坏ZIP及composer.lock并重装：先定位报错包对应ZIP文件，仅删该ZIP；再同步删除vendor/和composer.lock；最后执行composer install --no-cache --force-checksums。
Composer 下载失败后清缓存，不能直接 composer clear-cache 就完事——它大概率删错地方，反而延长恢复时间。真正要动的是损坏的 ZIP 文件和绑定它的校验锁。
看到 “Corrupted zip file” 错误时该删什么
这个错误不是网络问题，是本地缓存里某个 ZIP 文件写坏（比如断网、磁盘满、杀毒软件中断写入）。Composer 拿着坏文件去解压，必然失败，且不会自动跳过或重试。
- 从
composer install -v日志末尾找报错包名，例如Failed to extract vendor/symfony/console - 查真实缓存路径：
composer config --global cache-dir（Linux/macOS 通常是~/.composer/cache，Windows 是%APPDATA%\Composer\Cache） - 进
files/子目录，用包名模糊搜索：ls -l *symfony*console*.zip（Linux/macOS）或 PowerShell 中Get-ChildItem "$env:APPDATA\Composer\Cache\Files" -Filter "*console*.zip" - 只删匹配的 ZIP，别碰
repo/和vcs/——它们不参与解压流程
删 ZIP 后还报错？检查 composer.lock 是否同步清理
composer.lock 里硬编码了每个包的 dist.sha256 值。你删了 ZIP，但 lock 文件仍指着旧哈希，Composer 就拒绝安装，报错不变。
- 必须同步删掉：
composer.lock和vendor/（不能只删 vendor） - 推荐操作顺序：
rm -rf vendor composer.lock（Linux/macOS）或rd /s /q vendor & del composer.lock（Windows） - 重装时加两个关键参数：
composer install --no-cache --force-checksums。--no-cache强制跳过本地 ZIP，--force-checksums让校验失败立刻退出，避免污染vendor/
为什么反复执行 composer clear-cache 没用
composer clear-cache 默认清 files/、repo/、vcs/，但它不解决“校验锁死”问题。更关键的是：它删完所有 ZIP 后，Composer 仍可能复用已损坏的缓存副本——因为校验逻辑依赖 lock 文件，而不是缓存是否存在。
- 常见误操作：只运行
composer clear-cache，然后立刻composer install→ 依然报Corrupted zip file - 根本原因：lock 文件没动，Composer 读到旧
dist.sha256，就去files/找对应 ZIP；即使那个 ZIP 已被删，它也会尝试从缓存中重建（失败）或复用残留碎片 - CI 环境尤其危险：Docker 构建中若
composer.lock含旧源地址（如packagist.org），清缓存后重装仍走错路，根本拉不到镜像
下载卡在 “Downloading https://packagist.org/” 怎么办
这不是缓存损坏，是镜像没生效或元数据陈旧。此时删 ZIP 毫无意义，得刷新远程索引。
- 先确认镜像是否真生效：
composer config -g repo.packagist，输出应为国内地址（如https://mirrors.aliyun.com/composer/） - 手动删元数据根目录：
rm -rf $(composer config --global cache-dir)/repo/https---packagist.org/ - 再删
vendor/composer/installed.json和composer.lock - 验证是否成功：
composer update --dry-run -v，看到Downloading https://packagist.org/packages.json才算真正重载
最易被忽略的是 composer.lock —— 它不是缓存，却是整个安装流程的“判决书”。删 ZIP 不删 lock，等于拆了引擎盖却没拔钥匙，车还是开不动。
