答案：必须同步删除vendor和composer.lock后重装，因校验失败根源是composer.lock中硬编码的dist.sha256与新包不匹配；仅清缓存、换镜像或单删vendor均无效。
“hash verification failed”不是网络问题，是lock文件和包不匹配
Composer 报 hash verification failed 时，根本不是下载中断或网速慢，而是它拿 composer.lock 里硬编码的 dist.sha256 去比对刚下下来的 ZIP 包，发现字节不一致——哪怕只差一个空格，也立刻拒绝加载。这个校验发生在解压前，且完全绕过缓存机制。
常见误操作包括：
- 只运行
composer clear-cache：缓存目录清了，但composer.lock里的旧哈希毫发无损，重装仍失败 - 只删
vendor/：composer install会照着旧 lock 文件重新下载，校验逻辑照常触发 - 只换镜像源（如设为阿里云）：如果镜像本身返回了和 packagist.org 不一致的 dist 包但保留原哈希，校验“通过”但内容已被替换
必须同步删除 vendor 和 composer.lock，顺序不能错
修复动作不是“清理”，而是“重建”。composer.lock 是确定性快照，它的 content-hash 绑定了 composer.json 内容、PHP 版本、平台配置（如 config.platform.php）、甚至字段顺序。任何手动编辑、Git 合并残留（如 <<< HEAD）、或跨分支 composer update 都会导致哈希失准。
正确做法是：
- 先备份：
cp composer.lock composer.lock.bak - 删干净：
rm -rf vendor composer.lock（Windows 用rd /s /q vendor & del composer.lock） - 切回官方源保真：
composer config -g repo.packagist composer https://packagist.org - 再跑
composer install：此时会拉取完整packages.json，所有dist.sha256来自同一时刻快照
区分 checksum mismatch 和 content-length mismatch
二者报错位置、触发阶段、修复方式完全不同，混用会反复失败。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
Checksum mismatch（含 The checksum verification failed、sha256 does not match）：
- 发生在下载完成、解压前
- 根源在
composer.lock中记录的哈希与实际文件不符 - 必须删
vendor和composer.lock
Content-Length mismatch（含 received X bytes out of the expected Y）：
- 发生在下载过程中，HTTP 响应体长度异常
- 根源是本地缓存里存了半截 ZIP 包
- 只需
composer clear-cache+ 换镜像（如composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/），绝不能碰composer.lock
verify-checksums 是部署前最后一道防线，但默认不启用
composer verify-checksums 不是安装时的校验，而是对已安装的 vendor/ 目录做反向验证：读 composer.lock 里的 dist.sha256，再重新计算本地对应包目录的 SHA-256。但它默认不启用，且有关键限制：
- 必须加环境变量：
COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict（缺--strict时失败也返回 0，CI 无法感知） - 只校验 dist 类型包，
source（Git 克隆）或path类型包直接跳过 - 镜像配置不影响该命令行为——它只认 lock 文件，不关心你当初从哪下载的
- 若校验失败，说明 vendor 内容与 lock 承诺不一致，此时该查镜像一致性，而非关掉校验
真正容易被忽略的是：即使 composer install 成功，vendor 目录也可能被手动修改、NFS 并发写入损坏、或镜像静默替换 dist 包——这些都不会在 install 阶段暴露，只有 verify-checksums 能捕获。
