“hash verification failed”是composer因composer.lock中dist.sha256与下载包不匹配而主动拒绝加载；必须同步清除vendor/、composer.lock及缓存，并切官方源重装生成新锁文件，再等镜像同步后切换回用。
“hash verification failed”不是网络抖动或缓存脏了就能绕过去的错误——它意味着 Composer 拿 composer.lock 里硬编码的 dist.sha256 去比对刚下下来的 zip 包，结果不匹配。只清缓存、只换镜像、只删 vendor，95% 的情况都白忙。
为什么 composer clear-cache 不能修复校验失败
因为校验失败的源头不在缓存目录（~/.composer/cache 或 %APPDATA%\Composer\Cache），而在 composer.lock 文件中写死的 dist.sha256 值。这个哈希是上一次生成锁文件时记录的，和当前镜像返回的包版本/内容可能已不一致。
-
composer clear-cache只清下载缓存，composer.lock里的旧哈希完全不动 - 删了
vendor后跑composer install，仍会用旧 lock 文件去校验新包，必然失败 - Windows 用户常漏掉
del composer.lock，必须配对执行：rd /s /q vendor & del composer.lock
怎么确认当前生效的镜像源是不是你以为的那个
很多人运行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就以为设好了，但请求可能根本没走到镜像站——尤其 Composer 2.5+ 已废弃 repo.packagist 键名，正确字段是 repos.packagist.org。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 查全局配置：
composer config -g repos.packagist.org，输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}（注意末尾斜杠） - 查项目级覆盖：
composer config repositories，若出现"type": "vcs"或自定义 URL，全局镜像直接失效 - 手动验证通断：
curl -I https://mirrors.aliyun.com/composer/packages.json，必须秒回HTTP/2 200；卡住、返回 HTML 或 301 都说明镜像服务异常
真正有效的修复流程（顺序不能乱）
核心目标是让 Composer 丢弃所有旧上下文，用可信镜像拉取同一时刻的元数据快照，重新生成带当前有效哈希的 composer.lock。
- 先备份：
cp composer.lock composer.lock.bak - 切回官方源保真：
composer config -g --unset repos.packagist.org（或显式设为https://packagist.org） - 清缓存：
composer clear-cache，确认输出含Clearing cache (all) - 删干净：
rm -rf vendor composer.lock（Windows：rd /s /q vendor & del composer.lock） - 重装生成新锁：
composer install——此时会拉取完整packages.json，所有dist.sha256都来自同一时刻快照 - 等 10–30 分钟再切回阿里云；着急可换华为云镜像（已知同步更快）
镜像同步延迟之外的底层干扰点
如果按上述流程做完仍失败，问题大概率不在 Composer 层，而在系统或网络层：
- 系统时间偏差超过 5 分钟会导致 HTTPS 证书校验失败，间接使 zip 下载中断或截断——运行
date确认，Linux 可用timedatectl set-ntp true - 企业代理或防火墙篡改响应体（尤其 gzip 压缩流），导致 zip 文件损坏——临时关代理重试
- PHP 缺失
openssl或zlib扩展，无法解压 dist 包，却表现为校验失败——运行php -m | grep -E "(openssl|zlib)" - 磁盘满或权限不足，写入
vendor/时出错，残留半成品——检查df -h和ls -ld vendor
最麻烦的不是镜像慢，而是它返回了“看起来正常但哈希错”的包——这种错没法靠重试发现，只能靠同步清除元数据与安装物，强制重建信任链。
