唯一能真正修复checksum mismatch的做法是删除vendor和composer.lock后重新运行composer install；因为仅清缓存或只删vendor仍会复用composer.lock中已失效的旧校验和，导致校验失败。
直接删 vendor 和 composer.lock，再跑 composer install —— 这是唯一能真正修复 checksum mismatch 的做法。只清缓存、只换镜像、只删某个包目录，都可能复现错误。
为什么不能只清缓存或只删 vendor
composer clear-cache 只清理下载缓存，但 composer.lock 里仍存着旧的 checksum 值；composer install 会照着它去校验新下载的文件，而新版包的 hash 已变，必然失败。同样，只删 vendor/ 不删 composer.lock，重装时依然用错 checksum。
- 必须同时删除
vendor目录和composer.lock文件（Windows 用rd /s /q vendor & del composer.lock） - 确认当前没设国内镜像源干扰：运行
composer config -g --unset repos.packagist，再执行composer config -g repo.packagist composer https://packagist.org - 再运行
composer install，让 Composer 从头拉元数据、生成全新composer.lock
哪些操作只是绕过问题，不是修复
临时禁用校验看似快，但掩盖了根本问题，且有明确风险：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
COMPOSER_DISABLE_CHECKSUM_VERIFY=1 composer install：Composer 2.2+ 已标记为 deprecated，未来版本会移除 -
composer config -g secure-http false：不仅跳过 checksum，还允许 HTTP 源，极大降低安全性 -
--ignore-platform-reqs或--no-verify-checksums：这些参数根本不影响 checksum 校验逻辑，对 “checksum verification failed” 无效
国内镜像源同步延迟怎么判断和应对
阿里云、腾讯云等镜像通常 10–30 分钟同步一次 packagist.org，但如果你刚遇到某包报错，大概率是镜像还没跟上。不要在同步中途强制切回镜像。
- 先用官方源验证是否正常：
composer config -g repo.packagist composer https://packagist.org && composer clear-cache && composer install - 若官方源成功，说明是镜像延迟；等 30 分钟后再切回镜像，或改用已确认同步完成的镜像（如华为云有时比阿里云快）
- 别信“换镜像就能解决一切”——如果镜像本身返回了错误 checksum（极少见但存在），换源反而让问题更隐蔽
真正麻烦的是私有仓库或 fork 项目干扰：一旦 composer.json 里写了自定义 repositories，尤其是 type: vcs，它的 dist 包 URL 和 checksum 就可能和 packagist.org 不一致。这种情况下，连官方源也会报错，得先 composer config repositories 查清楚，再临时注释掉可疑源测试。
