直接删损坏ZIP比clear-cache更有效，因Failed to extract错误多由~/.composer/cache/files/中单个ZIP结构损坏引起，clear-cache会清空全部缓存却无法阻止Composer复用坏包，应精准定位并删除对应包名的ZIP文件。

直接删掉损坏的 ZIP 文件，比 composer clear-cache 更有效

报 Failed to extract 或 Corrupted zip file 时别清全量缓存

这类错误不是缓存目录整体出问题，而是 ~/.composer/cache/files/（Linux/macOS）或 %APPDATA%\Composer\Cache\Files\（Windows）里某个 ZIP 文件结构损坏——比如下载中断、磁盘写入异常、杀毒软件中途扫描并锁住文件。运行 composer clear-cache 会清空整个 files/，但 Composer 下次 install/update 时只校验哈希，不验证 ZIP 内部结构，可能直接复用坏包，继续报错。

• 先盯住 composer install -v 输出末尾，找到类似 Extracting vendor/symfony/console 的行，提取包名（如 symfony/console）
• 进缓存 files/ 目录，模糊搜索对应 ZIP：ls -l *symfony*console*.zip（Linux/macOS）或 PowerShell 中 Get-ChildItem "$env:APPDATA\Composer\Cache\Files" -Recurse -Filter "*console*.zip"
• 只删这个 ZIP，保留 repo/ 和 vcs/ ——它们不参与解压，删了反而拖慢后续元数据拉取

composer.lock 里的 dist.sha256 和新 ZIP 不匹配怎么办

删完坏 ZIP 后仍报错，大概率是 composer.lock 里硬编码的 dist.sha256 值和新下载内容对不上——Composer 拿旧哈希去校验新 ZIP，自然失败。

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• 必须同步删掉 vendor/ 和 composer.lock，否则 install 会反复卡在校验环节
• 再跑 composer install --no-cache --prefer-dist：其中 --no-cache 强制跳过所有缓存查找，确保重下且重算哈希
• 别用 update 替代——它会尝试复用 lock 里的旧约束，可能又拉回已损坏的缓存路径

删 ZIP 前必须确认它没被任何项目引用

一个 ZIP 文件是否“可删”，取决于它是否出现在当前所有项目的 composer.lock 中。误删正在用的版本，下次 install 会直接失败（Could not fetch 或 404）。

• 遍历所有项目，用 jq -r '.packages[] | "\(.name) \(.version)"' 提取全部 name version 对
• 进 cache/files/，检查每个 ZIP 文件名（如 symfony-console-5.4.33.zip）是否在上述列表中
• 只删那些文件名匹配但版本号完全未出现的 ZIP；Windows 用户注意路径分隔符，用 dir /s /b 配合 findstr 更可靠

真正麻烦的不是删文件，而是判断“这个 ZIP 究竟还用不用”。缓存目录里混着多个项目、多个版本的归档，靠 clear-cache 一刀切，反而容易把还在用的包也清掉——手动定位+精准删除，才是处理损坏缓存最稳的方式。