Composer校验失败时必须同步删除vendor和composer.lock并重装，因错误根源在于lock文件中硬编码的dist.sha256与新下载包不匹配，仅清缓存或只删vendor无法更新该哈希值。
Composer 不会自动重试损坏 ZIP 包，也不会在 vendor 已存在时重新校验哈希——它只在校验失败时直接报错中断，不重拉、不跳过、不降级。
Failed to extract vendor/package 是 ZIP 本身坏了
这个错误不是网络抖动或权限问题，而是 ~/.composer/cache/files/（Linux/macOS）或 %APPDATA%\Composer\Cache\files\（Windows）里缓存的 ZIP 文件 SHA256 校验失败。Composer 下载后立即计算哈希，不匹配就拒绝解压，且不会自动重试下载，更不会 fallback 到其他镜像或源。
- 典型现象：
Failed to extract vendor/symfony/console: unable to open archive或Content-Length mismatch - 只删
vendor/没用：坏 ZIP 还在缓存里，重装时照样被读取 - 必须先
composer clear-cache，再确认缓存目录是否真清空：ls -la $(composer config --global cache-dir)/files/ - 若仅某个包反复出错（如
monolog/monolog），可精准清理：rm -rf $(composer config --global cache-dir)/files/monolog/monolog
composer install 默认跳过哈希校验（只要 vendor 存在）
composer install 的行为分两层：首次安装时校验 dist.sha256；但只要 vendor/ 目录存在且结构完整，后续运行就完全跳过所有哈希比对，直接加载。这意味着：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 手动改过
vendor/autoload.php或某个类文件，composer dump-autoload不会发现，composer install也不报错 -
composer.lock里记录的哈希和实际 vendor 内容已不一致？composer install默认沉默接受，直到你运行composer update或加--prefer-dist - 唯一能主动验证 vendor 真实性的命令是
composer verify-checksums --strict，但它需启用COMPOSER_EXPERIMENTAL=1，且跳过type: "package"或无dist.sha256字段的包
--no-cache 是绕过缓存强制重拉的唯一可靠方式
composer install 默认优先走本地缓存，即使刚清过 cache，也可能因残留元数据或并发写入而跳过下载。必须显式禁用缓存逻辑：
-
composer install --no-cache强制从镜像源重新拉 ZIP 并执行完整 SHA256 校验 - CI/CD 中光靠
--no-cache不保险：流水线常挂载持久化缓存目录，得配合COMPOSER_CACHE_DIR=/dev/null composer install --no-cache -
--ignore-platform-reqs和--no-plugins不影响哈希校验，别指望它们解决 checksum mismatch - 临时绕过校验的
COMPOSER_DISABLE_CHECKSUM_VERIFY=1在 Composer 2.2+ 已 deprecated，未来版本会移除，且它不更新composer.lock
镜像配置失效会让损坏更难排查
你以为在走国内镜像，实际请求发到了 packagist.org，结果下载慢、中断、校验失败——而错误日志里根本不会提示“正在从 packagist.org 拉取”。
- 验证全局镜像：
composer config -g repos.packagist，输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 检查项目级覆盖：
grep -A 5 '"repositories"' ./composer.json，项目级"repositories"会完全屏蔽全局镜像 - 验证真实请求地址：Linux/macOS 可用
strace -etrace=network composer install 2>&1 | grep 'connect'，看连接 IP 是否指向镜像服务器 - 镜像服务异常（如返回 HTML 页面或卡住）比 ZIP 损坏更隐蔽，先
curl -I https://mirrors.aliyun.com/composer/packages.json确认 HTTP/2 200
真正麻烦的不是 ZIP 坏了，而是你不知道它什么时候坏的、谁改过 vendor 里的文件、镜像有没有偷偷替换 dist 包却没透传原始哈希——这些点都藏在校验链路之外，得靠人工交叉验证。
