必须同步删除 vendor 和 composer.lock，否则因 lock 文件中硬编码的 dist.sha256 与当前包不匹配，仅清缓存或删 vendor 无效；需先切回官方源、验证镜像同步状态、排除项目级 repositories 干扰。
“hash verification failed”不是网络或缓存问题，而是 composer.lock 里硬编码的 dist.sha256 和当前下载包内容不一致——必须同步删掉 vendor 和 composer.lock，否则任何操作都无效。
为什么只删 vendor 或只清缓存没用
Composer 安装时默认信任 composer.lock，它会严格按里面记录的 dist.url 和 dist.sha256 去校验新下载的 ZIP 包。哪怕你已切阿里云镜像、清了 ~/.composer/cache，只要 composer.lock 没变，校验逻辑就永远拿旧哈希比对新包。
- 只运行
composer clear-cache：只删本地 ZIP 缓存，composer.lock里的哈希纹丝不动 - 只删
vendor/目录：下次composer install仍读旧 lock，必然再失败 - Windows 用户常漏掉
del composer.lock，必须配对执行：rd /s /q vendor & del composer.lock - Linux/macOS 对应命令是：
rm -rf vendor composer.lock（注意空格，不是rm -rf vendor/ composer.lock）
删之前必须先切回官方源
国内镜像（如阿里云、腾讯云）存在 10–30 分钟元数据同步延迟，你本地 composer.lock 可能记录的是上周的哈希，而镜像已更新包但未同步元数据，二者天然不匹配。直接在镜像未同步完成时重装，等于拿不确定一致的源验证确定过期的哈希。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先解除全局镜像：
composer config -g --unset repos.packagist.org（Composer 2.5+ 推荐字段名） - 确认生效：
composer config -g repos.packagist.org应输出为空或明确指向https://packagist.org - 别信
composer config输出就完事——唯一可信证据是composer install -vvv日志里第一行Downloading的 URL - 删完再跑
composer install，此时所有哈希来自同一时刻的官方快照，自然对齐
换回镜像前要手动验证同步状态
别急着 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就完事。镜像是否真同步完成，得看它返回的元数据和官方是否一致。
- 打开浏览器，访问
https://packagist.org/packages/vendor/package-name（把vendor/package-name替成报错包） - 再访问对应镜像地址：
https://mirrors.aliyun.com/composer/p/vendor/package-name.json - 对比两者 JSON 中的
versions列表和目标版本下的dist.sha256是否完全一致 - 若镜像返回 404 或缺失目标版本，说明尚未同步——等满 30 分钟再试，或换华为云镜像（
https://mirrors.huaweicloud.com/repository/php/）
项目级 repositories 配置会彻底屏蔽全局镜像
哪怕你全局配置写得再对，只要项目根目录的 composer.json 里有 "repositories" 字段，Composer 就会优先生效，全局设置形同虚设。
- 检查项目级覆盖：
composer config repositories，若有输出，说明全局镜像已被屏蔽 - 查看
composer.json文件中是否存在"repositories"块，尤其注意是否写了无效 URL 或已停更的源（如已下线的 phpcomposer.com） - 临时注释掉该字段再试，或改用
"packagist.org": false显式禁用 packagist.org，避免 Composer 1.x 解析崩溃 - 删完记得
composer clear-cache，否则~/.composer/cache/repo/下残留的旧快照仍会误导请求
最常被忽略的一点：哈希不匹配往往不是孤立事件，它背后可能是镜像滞后、系统时间漂移（偏差 >5 分钟会触发 JWT 签名拒绝）、多人协作时未提交 composer.lock，或是 CI 环境复用了脏缓存。不要只盯着删文件，先确认你真正面对的是哪一层脱节。
