Composer不会自动检测或修复缓存损坏，需手动定位vcs/裸仓库或files/ZIP文件并清理，同时删除composer.lock和vendor/后加--no-cache重试。

Composer 不会自动检测缓存损坏，也不会主动重建——它只会静默复用已损坏的裸仓库或 ZIP 文件，直到卡住、报错或你手动干预。

composer update 卡在 git clone 时怎么确认是缓存损坏

• 日志里出现 Cloning into bare repository '/home/user/.composer/cache/vcs/https---github.com-vendor-package.git'，说明它正试图复用缓存中的裸仓库
• 进入该路径，执行 git --git-dir=. show-ref --head
  • 若报 fatal: not a git repository 或无任何输出，就是裸仓库损坏
  • 若输出正常（如 c8f3a7e5 refs/heads/main），说明缓存完好，问题在别处

损坏常见于：WSL 跨文件系统中断写入、Ctrl+C 杀掉 git clone --mirror、磁盘满或权限异常。

Corrupted zip file 错误怎么定位并清理对应缓存

• 从错误日志中提取包名，例如 Failed to extract vendor/symfony/console
• 查全局缓存路径：composer config --global cache-dir（通常为 ~/.composer/cache）
• 进入 files/ 子目录，按包名模糊搜索：
  • Linux/macOS：ls -l symfonyconsole*.zip
  • Windows PowerShell：Get-ChildItem "$env:APPDATA\Composer\Cache\Files" -Filter "console.zip"
• 只删匹配的 ZIP 文件，不要碰 vcs/ 或 repo/
• 同步删掉 composer.lock 和 vendor/，否则校验仍失败

不删 lock 文件，Composer 就会继续拿着旧 dist.sha256 去找那个已不存在（或已删但没清锁）的 ZIP。

为什么 composer clear-cache 经常没用

• 它清的是整个 files/、vcs/、repo/，但：
  • 不动 composer.lock，所以校验逻辑照常运行，依然报错
  • 不删 vendor/，所以已有包不会重装，autoload 也不刷新
  • 不处理 vcs/ 下部分损坏（比如只剩空目录）的裸仓库，删完又重建时可能再次中断

真正要动的组合是：

Academic Composer Upload

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

下载

• 损坏裸仓库 → 删对应 vcs/xxx.git 目录 + 加 --no-cache 重试
• 损坏 ZIP → 删对应 ZIP + 删 composer.lock + 删 vendor/ + composer install --no-cache --force-checksums

自动检测不存在，但你可以用脚本封装验证逻辑：检查 vcs/ 下每个裸仓库是否能 show-ref，或扫描 files/ 中 ZIP 是否可解压头 —— 但这不是 Composer 内置行为，得自己写。

缓存损坏本身不可预测，但它的表现高度一致：卡住、静默、报哈希错、拉到旧 commit。盯住 -vvv 日志里的那一行路径，比猜“是不是网络问题”快十倍。