唯一有效动作是同步删除vendor和composer.lock后重跑composer install，因为校验失败根源在于composer.lock中硬编码的dist.sha256与新下载包不匹配，仅清缓存、换镜像或只删vendor均无法更新该哈希值。
删 vendor 和 composer.lock 是唯一有效动作，其他操作基本白忙。 因为校验失败的根源不在缓存、不在网络、也不在镜像本身，而在于 composer.lock 里存的 dist.sha256 值已经和当前镜像返回的包不一致——这个值不会随换源或清缓存自动更新。
为什么只清缓存或只删 vendor 一定失败
Composer 安装时，会严格比对 composer.lock 中记录的 dist.sha256 和刚下载下来的 zip 包实际哈希。这个比对发生在下载之后、解压之前。
-
composer clear-cache只清~/.composer/cache/，composer.lock里的旧哈希纹丝不动 - 只
rm -rf vendor后跑composer install，仍用旧 lock 文件去校验新包，必然报The checksum verification failed - Windows 用户漏掉
del composer.lock（只执行rd /s /q vendor），结果一样失败
怎么确认当前生效的镜像源是不是你以为的那个
很多人以为 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就设好了，其实请求根本没走到镜像站。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 查全局配置：
composer config -g repositories.packagist.org，正确输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}（注意末尾斜杠） - 查项目级覆盖：
composer config repositories，若出现"type": "vcs"或自定义 URL，全局镜像直接被绕过 - 手动测通断：
curl -I https://mirrors.aliyun.com/composer/packages.json，必须秒回HTTP/2 200；卡住、返回 HTML 或 301，说明镜像服务异常或被代理拦截
强制从备用镜像恢复的完整动作链
不是“换一个镜像”，而是让 Composer 忘掉旧上下文，用新镜像从头建一套可信元数据。步骤缺一不可：
- 清缓存：
composer clear-cache，确认输出含Clearing cache (all) - 删干净：
rm -rf vendor composer.lock（Linux/macOS）或rd /s /q vendor & del composer.lock（Windows） - 切镜像并验证：
composer config -g repositories.packagist.org '{"type":"composer","url":"https://mirrors.huaweicloud.com/composer/"}'，再用composer config -g repositories.packagist.org确认输出 - 重装生成新锁：
composer install——此时所有dist.sha256都来自华为云同一时刻的快照
备用镜像也失效时的底层排查点
按上述流程做完仍失败，问题大概率不在 Composer 层，而在系统或网络层：
- 系统时间偏差超过 5 分钟：运行
date确认，timedatectl set-ntp true同步（Linux） - 企业代理或防火墙篡改响应体（尤其 gzip 流）：临时关代理再试
- PHP 缺失
openssl或zlib扩展：运行php -m | grep -E "(openssl|zlib)" - 磁盘满或权限不足：检查
df -h和ls -ld vendor
真正麻烦的是镜像返回了“看起来正常但哈希错”的包——这种错误不会报网络超时，也不会提示证书异常，只会安静地让你重装十次。
