哈希校验失败的根本原因是 composer.lock 中存储的 SHA256 值过期，与实际下载包不匹配；唯一彻底修复方式是同时删除 vendor 目录和 composer.lock 文件后重新安装。
哈希校验失败不是文件损坏，而是 composer.lock 里存着过期的 SHA256 值，和你这次下载的包对不上——删 vendor 和 composer.lock 一起重装，是唯一真正修复的方式。
为什么只删 vendor 或只清缓存没用
Composer 校验时根本不看缓存或 vendor 目录里的旧文件，它只做一件事：拿 composer.lock 里记录的 dist.sha256，去比对刚下载下来的 zip 包内容。一旦 lock 文件里的哈希来自作者重推过的 tag、或镜像源还没同步的新版本，校验必然失败。
-
composer clear-cache只删下载缓存，composer.lock里的错误哈希纹丝不动 - 只
rm -rf vendor，再跑composer install，还是会照着旧 lock 去校验新包 - Windows 下必须同时执行：
rd /s /q vendor & del composer.lock，缺一不可
怎么确认是不是镜像源拖了后腿
国内镜像（阿里云、腾讯云）通常有 10–30 分钟同步延迟，尤其遇到新发版或 dev 分支变更。不能靠“换一个镜像”蒙混过关，得验证。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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 && composer config -g repo.packagist composer https://packagist.org - 再清缓存：
composer clear-cache - 最后装一次：
composer install——如果成功，基本就是镜像没跟上 - 别急着切回去；等 30 分钟，或直接换华为云（已知同步更快）
- 注意：
composer config repositories能看到真实生效的源，type: vcs 配置会覆盖全局镜像
哪些操作只是绕过，不是修复
临时禁用校验能让你命令跑通，但掩盖问题、不修正 lock、且在 Composer 2.2+ 已被标记为 deprecated。上线环境绝对禁止。
-
COMPOSER_DISABLE_CHECKSUM_VERIFY=1 composer install：跳过校验，但下次不带这个变量照样报错；未来版本会移除 -
composer config -g secure-http false：不仅关 checksum，还允许 HTTP 源，风险极高 -
--ignore-platform-reqs或--no-plugins：完全不影响 checksum 校验逻辑，对 “checksum verification failed” 无效 - 手动改
composer.lock里的sha256字段：极危险，可能让依赖链断裂或引入不一致版本
容易被忽略的底层干扰点
真正难排查的 case 往往不在 Composer 层，而在系统或网络层——这些不会报明确错误，但会让哈希必然失败。
- 系统时间偏差 > 3 分钟：HTTPS 证书验证失败 → 下载截断 → 文件不完整 → 哈希必错
- 企业代理或防火墙：某些中间设备会重写响应体（比如注入脚本、压缩 HTML），哪怕只动一个字节，
sha256sum就对不上 -
vendor/autoload.php不参与任何校验流程，lock 文件里压根没它的条目；但它被篡改后危害极大，CI 中应固化其哈希并单独校验 - 生产环境必须设
vendor/为只读：chmod -R 555 vendor/（Linux）或容器启用readonlyRootFilesystem: true
