Composer update慢的根源是未清理ZIP包、packages.json快照和composer.lock三处关键缓存；需分别删除损坏ZIP、repo/下元数据、installed.json及composer.lock，再执行update --dry-run -v验证是否重新下载packages.json。
composer update慢，不是缓存没清，而是缓存没清对地方
直接跑 composer clear-cache 很大概率没用——它只删 ~/.composer/cache/files/（ZIP包）、repo/（元数据快照）、vcs/（Git克隆），但 update 卡住的真正瓶颈往往在三处：已损坏的 ZIP、过期的 packages.json 快照、以及被锁死的 composer.lock。你看到“Downloading”卡住或反复 Extracting 失败，八成是其中一处没动。
Failed to extract 或 Corrupted zip file？删具体 ZIP 文件
这类错误不是网络问题，是本地 ZIP 文件下载中断或磁盘写异常导致的校验失败。Composer 不会自动重下，只会反复尝试解压那个坏文件。
- 盯紧
composer install -v输出末尾，找到类似Extracting symfony/console v6.4.0的行，提取出包名和版本 - 查缓存路径：
composer config --global cache-dir - 进
files/子目录，按包名搜索：ls -l *symfony*console*.zip（Linux/macOS）或 PowerShell 中Get-ChildItem "$env:APPDATA\Composer\Cache\Files" -Filter "*console*.zip" - 只删匹配的 ZIP，别碰
repo/和vcs/——它们不参与解压流程 - 删完再跑
composer install --no-cache，强制跳过缓存重新拉取
update 仍装旧版？必须同步清理三处关键状态
composer clear-cache 不动 vendor/composer/installed.json 和 composer.lock，而这两者才是 Composer 判断“该不该更新”的依据。留着它们，update 就永远认为“当前版本就是最新”。
- 先运行
composer clear-cache（清基础缓存，避免干扰） - 再删元数据快照：
rm -rf $(composer config --global cache-dir)/repo/https---packagist.org/ - 删本地安装记录：
rm -f vendor/composer/installed.json - 删锁文件：
rm -f composer.lock - 最后执行
composer update
Windows 用户注意：$(composer config --global cache-dir) 在 PowerShell 中需补 .Trim()，或直接用 $env:APPDATA\Composer\Cache\repo\https---packagist.org\。
验证 metadata 是否真刷新了
别信“命令跑完了就 OK”，要亲眼看到 Composer 重新拉远端索引。
- 运行
composer update --dry-run -v - 紧盯输出里有没有
Downloading https://packagist.org/packages.json - 如果只有
Reading /path/to/cache//packages.json，说明repo/没删干净，重来 - 额外提醒：若项目设了
"minimum-stability": "stable"，而目标包只发了dev或beta版，那即使 metadata 刷新了也看不到——这不是缓存问题，是约束本身在过滤
最易被忽略的是 composer.lock。很多人删了缓存、删了 installed.json，却留着它，结果 update 依然原地不动——因为 Composer 认为“锁文件没变，就不需要动版本”。
