正确做法是先定位损坏包再手动删除对应ZIP文件，再同步清理vendor/和composer.lock，最后执行composer install --no-cache --force-checksums重装。
看到“Failed to extract”别急着清全量缓存
这类错误本质是 ~/.composer/cache/files/ 下某个 ZIP 文件损坏（比如下载中断、磁盘写异常），不是网络不通，也不是镜像失效。Composer 拿着坏 ZIP 去解压，直接报错卡住，不会自动跳过或重试。
常见错误现象包括：
Corrupted zip file: monolog/monologFailed to extract vendor/symfony/consoleCorrupted cache file
此时执行 composer clear-cache 会删掉所有包，但 Composer 默认仍可能复用已损坏的缓存副本——它不重新下载，只校验旧哈希，结果还是失败。
正确做法是先定位再清理：
- 盯住
composer install -v输出末尾，找Extracting或Downloading后紧跟着的包路径 - 查缓存位置：
composer config --global cache-dir（Linux/macOS 通常是~/.composer/cache，Windows 是%APPDATA%\Composer\Cache） - 进
files/子目录，用包名模糊搜索 ZIP：ls -l *symfony*console*.zip（Linux/macOS）或 PowerShell 中Get-ChildItem "$env:APPDATA\Composer\Cache\Files" -Recurse -Filter "*console*.zip" - 只删匹配的 ZIP，别碰
repo/和vcs/—— 它们不参与解压流程
删完 ZIP 还报错？检查 composer.lock 和 vendor 是否同步清理
校验失败根源在 composer.lock 中硬编码的 dist.sha256 值。它和当前缓存 ZIP 不匹配，Composer 就拒绝安装。只清缓存、只删 vendor/ 都绕不过这个检查。
必须同步操作：
- 备份：
cp composer.lock composer.lock.bak - 删干净：
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.lock 就白删 vendor/；CI 环境中尤其要注意，composer.lock 若含旧源地址，重装永远走错路。
镜像配置写对了但没生效？验证三要素缺一不可
镜像配置静默失效最常见于三个细节出错：键名、type 值、URL 结尾斜杠。命令跑完没报错，但 composer install -vvv 日志里仍出现 packagist.org，说明根本没接管。
必须满足：
- 键名必须是
repo.packagist（不是repos.packagist，多一个s就写进无效字段） - 中间必须显式写
composer作为type值：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - URL 必须以
/结尾，否则拼出的路径是/composerpackages.json→ 404
验证是否真写进去了：composer config -g repo.packagist 输出必须是完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null 或仍是官方地址，说明压根没存成功。
更可靠验证方式是看真实请求：composer install -vvv --no-progress | grep "GET https"，确认域名是否为镜像地址。
清完缓存还卡在 “Loading composer repositories”？问题不在 Composer 缓存里
“Redirecting to http://” 或卡在加载仓库，大概率是系统层网络劫持：代理、/etc/hosts、DNS 污染导致 302 循环，和 Composer 本身无关。composer clear-cache 对此完全无效。
快速验证方法：
- 绕过 Composer 直连：
curl -v https://packagist.org/packages.json，看是否有和 <code> 指向本地地址 - DNS 层检查：
nslookup packagist.org，确认返回 IP 是官方地址（如146.75.119.170）
临时解决（最小干预）：
- 清空代理变量：
HTTP_PROXY= HTTPS_PROXY= composer install - Linux/macOS 强制解析真实 IP：
curl --resolve packagist.org:443:146.75.119.170 https://packagist.org/packages.json - Windows 手动指定 IP + Host 头：
curl -H "Host: packagist.org" https://146.75.119.170/packages.json
真正麻烦的是权限错位或项目级 repositories 字段覆盖全局配置——这种问题不会报错，只会让你反复执行 clear-cache 却毫无进展。
