“hash verification failed”是composer因下载包与composer.lock中dist.sha256不匹配而主动拒绝加载；需同步清除vendor/、composer.lock、缓存，并确保镜像源生效且系统环境（时间、代理、磁盘、php扩展）正常。
“hash verification failed”不是网络问题，是 Composer 主动拒绝加载——它发现下载的 zip 包和 composer.lock 里记的 dist.sha256 对不上。只清缓存、只删 vendor/、换镜像不验证配置，95% 的情况都白忙。
怎么确认当前生效的镜像源是不是你以为的那个
很多人运行了 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，会直接绕过全局镜像 - 手动测通断：
curl -I https://mirrors.aliyun.com/composer/packages.json，必须秒回HTTP/2 200才算真通；企业内网常见 TLS 握手卡死，可临时关 SSL 验证：composer config -g secure-http false（完事后务必恢复）
为什么删 vendor/ 后跑 composer install 还报错
因为 composer install 默认复用现有 composer.lock，而这个文件里存的哈希值已经和当前镜像返回的包不一致了。删 vendor/ 只是清安装物，没动元数据源。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer clear-cache只清~/.composer/cache/，composer.lock里的错误哈希纹丝不动 - 只
rm -rf vendor再装，Composer 仍拿旧dist.sha256去比对新下载的 zip，必然失败 - Windows 用户必须同时执行：
rd /s /q vendor & del composer.lock；Linux/macOS 是rm -rf vendor composer.lock - 删之前建议先备份：
cp composer.lock composer.lock.bak
彻底修复必须同步清除元数据与安装物
唯一真正有效的做法是让 Composer 重新拉取最新元数据、生成带当前有效哈希的新锁文件。这要求环境干净、源可信、时间准确。
- 先切回官方源保真：
composer config -g --unset repos.packagist（或显式设为https://packagist.org） - 清缓存：
composer clear-cache - 删干净：
rm -rf vendor composer.lock（Windows 用rd /s /q vendor & del composer.lock） - 重装生成新锁：
composer install—— 此时会拉取完整packages.json，所有dist.sha256都来自同一时刻快照 - 等 10–30 分钟再切回阿里云镜像；着急就换华为云，已知同步更快
容易被忽略的底层干扰点
真正难排查的 case 往往不在 Composer 层，而在系统或网络层——这些不会报明确错误，但会让哈希必然失败。
- 系统时间偏差 > 3 分钟：HTTPS 证书验证失败 → 下载截断 → 文件不完整 → 哈希必错
- 代理或企业网关篡改响应体（如压缩过滤、注入脚本），导致 zip 实际内容与源不一致
- 磁盘满或权限不足导致
~/.composer/cache/repo/下的packages.json写入截断，缺失shasum字段 - PHP OpenSSL 扩展异常或 hash 扩展未启用，会影响本地哈希计算逻辑（可用
php -m | grep -E "(hash|openssl)"检查）
哈希校验本身很轻量，问题从来不在它太严，而在于你没让元数据、缓存、镜像、lock 文件这四者对齐。尤其是 composer.lock，它不是“历史记录”，而是当前安装的强制契约——改它不如重建它。
