必须同步清除vendor/和composer.lock，并切回官方源重装生成新锁文件，因为旧lock中dist.sha256与镜像包不匹配导致校验失败；仅清缓存或删vendor无效。
怎么确认当前生效的镜像源是不是你以为的那个
很多人执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就以为搞定了，结果请求根本没走到镜像站。先查全局配置：composer config -g repos.packagist，正确输出必须是 {"type":"composer","url":"https://mirrors.aliyun.com/composer/"}；如果还是 packagist.org，说明没设上。再查项目级覆盖：composer config repositories，若出现 "type": "vcs" 或自定义 URL，会直接绕过全局镜像。企业内网常见 DNS 解析失败或 TLS 握手卡死，手动测通最可靠：curl -I https://mirrors.aliyun.com/composer/packages.json，必须秒回 HTTP/2 200 才算真通。
为什么删 vendor 后跑 composer install 还报 hash verification failed
因为 composer install 默认复用现有 composer.lock，而这个文件里存的 dist.sha256 已经和当前镜像返回的包不一致了。只删 vendor/ 是白忙——Composer 仍拿旧哈希去比对新下载的 zip，必然失败。
- Windows 用户必须同时执行：
rd /s /q vendor & del composer.lock - Linux/macOS 是：
rm -rf vendor composer.lock - 删之前建议备份：
cp composer.lock composer.lock.bak - 别只清缓存、别只换镜像、别只删 vendor —— 元数据（lock）和安装物（vendor）必须同步清除
彻底修复必须切回官方源重装生成新锁文件
唯一真正有效的做法是让 Composer 重新拉取最新元数据、生成带当前有效哈希的新锁文件。这要求环境干净、源可信、时间准确。
- 先切回官方源保真：
composer config -g --unset repos.packagist - 清缓存：
composer clear-cache - 删干净：
rm -rf vendor composer.lock（Windows 用rd /s /q vendor & del composer.lock） - 重装生成新锁：
composer install—— 此时会拉取完整packages.json，所有dist.sha256都来自同一时刻快照 - 等 10–30 分钟再切回阿里云镜像；着急就换华为云，已知同步更快
哪些操作只是绕过，不是修复
临时禁用校验能让你跑通命令，但根本问题还在，且 Composer 2.2+ 已明确弃用相关机制。
-
COMPOSER_DISABLE_CHECKSUM_VERIFY=1 composer install：已标记为 deprecated，未来版本会移除 -
composer config -g secure-http false：不仅跳过 checksum，还允许不安全的 HTTP 源，风险极高 -
--no-verify-checksums或--ignore-platform-reqs：这些参数根本不影响 checksum 校验逻辑，对hash verification failed无效 -
composer update vendor/package-name：不会刷新整个 lock 的校验上下文，可能漏掉依赖链中其他包的哈希冲突
哈希校验本身很轻量，问题从来不在它太严，而在于你没让 composer.lock、源、缓存、Composer 版本这四者对齐。真正难排查的 case 往往不在 Composer 层，而在系统或网络层——比如时间不同步、代理篡改响应体、PHP OpenSSL 扩展异常，这些都得单独验证。
