根本原因是包文件损坏或版本错位，需清除缓存、删除vendor和composer.lock后重新install；--force-checksums仅强制失败退出，不修复问题。
Composer 报 SHA1（或更常见的是 SHA256）不匹配，根本不是“网络传输故障”本身要修，而是它已成功拦截了因网络中断、代理污染、镜像滞后或本地篡改导致的**包文件损坏或版本错位**——必须用对应手段清除错误状态，不能靠重试或调超时解决。
为什么composer install卡在 checksum mismatch 不是网络问题
报 Invalid checksum for 或 file hash mismatch 时，Composer 已完成下载和解压，正在比对：它拿 composer.lock 里记录的哈希值，去核验你本地磁盘上那个实际文件的哈希。不一致 ≠ 下载失败，而是「内容对不上」。
- 常见诱因包括：国内镜像源同步延迟（比如新 tag 刚发，镜像还没拉到），包作者重推了同一 tag，你手动删过
vendor/某个子目录，或企业代理偷偷注入了 HTML 脚本 -
curl -I https://mirrors.aliyun.com/composer/packages.json返回 200 并不表示包文件也完好——镜像可能缓存了旧版 zip，但packages.json已更新 - 加
--timeout=300或--prefer-dist对这类报错完全无效，因为校验发生在解压后、加载前，和连接阶段无关
强制校验参数--force-checksums到底起什么作用
这个参数不是“修复哈希错”，而是让校验失败时立刻报错退出，不给损坏包留任何执行机会——属于最后一道防线，防止 Composer 解压一个截断的 zip 后继续生成残缺的 vendor/ 目录。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 仅对本次命令中需下载的新包生效；已缓存的损坏 zip 仍会被复用，所以必须配合
composer clear-cache - 启用后，一旦哈希不匹配，直接抛出
Invalid archive signature并终止，不会走到 autoload 或 class not found 那步 - 它不改变
composer.lock，也不修复已安装包；若你已经看到Class not found，说明校验已被绕过，此时再加该参数也没用
真正能修复的三步操作（不是“清理缓存”就完事）
只清缓存或只删 vendor/ 都不行——composer.lock 里还存着旧哈希，重装时照样拿错值去比对。必须让锁文件和实际文件重新对齐。
- 运行
composer clear-cache：清掉全局缓存（~/.composer/cache/），避免复用损坏 zip - 删除
vendor/和composer.lock两个文件/目录（Windows 用rd /s /q vendor & del composer.lock） - 重新运行
composer install --prefer-dist：强制走 dist 包（zip/tar），跳过 git clone 可能触发的 API 限流或证书问题
容易被忽略的底层干扰点
很多 case 看似哈希错，实则根子不在 Composer，而在环境层。排查时别一头扎进配置文件。
- 系统时间偏差 > 3 分钟：会导致 HTTPS 证书验证失败 → 下载截断 → 文件不完整 → 哈希必败；用
date检查，Docker 容器里尤其常见 - 企业防火墙或中间代理：某些设备会重写响应体（哪怕只加一个空格），哈希立刻失效；可临时用
curl -v https://mirrors.aliyun.com/composer/dist/monolog/monolog/2.9.0.0-zip对比响应头里的Content-Length和实际 body 长度 - 私有仓库未配签名：若用了 Satis 或自建 Packagist，启用
--force-checksums后批量报错，说明该仓库没发布带校验签名的包，得先补签名逻辑
