必须同步删除vendor和composer.lock后重装，因校验失败根源是composer.lock中硬编码的dist.sha256与新包不匹配；仅清缓存、换镜像或单删vendor均无效，须确保镜像源生效、系统时间准确且四者对齐。
必须同步删除 vendor 和 composer.lock，再切回官方源重装——只清缓存、只删 vendor 或只换镜像，全部无效。
为什么 composer clear-cache 没用
校验失败的根源不在本地缓存里，而在 composer.lock 文件中硬编码的 dist.sha256 值。Composer 安装时会拿这个哈希去比对刚下载的 ZIP 包，哪怕镜像返回的是合法但不同版本的包，只要哈希不一致就直接报错。
-
composer clear-cache只清~/.composer/cache（Linux/macOS）或%APPDATA%\Composer\Cache（Windows），对composer.lock完全无影响 - 即使你已切回官方源，只要
composer.lock里还记着旧镜像缓存包的哈希，composer install就一定会失败 - Windows 用户常漏掉
del composer.lock，必须和rd /s /q vendor配对执行
怎么确认当前到底连的是哪个镜像
别信配置命令是否“看起来成功”，要验证请求真走到了目标地址：
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 repo.packagist，输出必须是类似{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}的完整 JSON；如果还是https://packagist.org或空，说明没设上 - 查项目级覆盖：
composer config repositories，若出现"type": "vcs"或自定义 URL，会直接绕过镜像机制 - 手动验证通断：
curl -I https://mirrors.aliyun.com/composer/packages.json，必须秒回HTTP/2 200；企业内网常见 TLS 握手卡死，可临时关 SSL 验证：composer config -g secure-http false（完事后务必恢复）
真正有效的修复流程（顺序不能乱）
删之前建议先备份：cp composer.lock composer.lock.bak。以下步骤缺一不可：
- 切回官方源保真：
composer config -g --unset repos.packagist（或显式设为https://repo.packagist.org） - 清缓存：
composer clear-cache - 删干净：
rm -rf vendor composer.lock（Windows 用rd /s /q vendor & del composer.lock） - 重装生成新锁：
composer install——此时拉取的是完整packages.json快照，所有dist.sha256都来自同一时刻
哪些操作只是绕过，不是修复
临时禁用校验能让你跑通命令，但根本问题还在：
-
composer install --no-cache && COMPOSER_REPO_PACKAGES=https://repo.packagist.org composer install可用于快速验证是否镜像污染，但不解决锁文件残留问题 -
--ignore-platform-reqs或修改config.platform.php对 checksum mismatch 完全无效，它们只跳过 PHP 版本或扩展检查 - Composer 2.2+ 已明确弃用弱校验机制，强行绕过可能掩盖更深层的镜像同步缺陷
checksum mismatch 的本质是镜像服务端缓存与官方源脱节，不是你本地环境脏。最易被忽略的是：删了 vendor 却忘了 composer.lock，或者以为改了全局配置就生效，结果项目级 repositories 字段把它彻底屏蔽了。
