composer.lock的哈希值不随镜像切换而改变，其dist.sha256始终源自packagist官方快照；镜像仅影响元数据拉取路径和dist包下载地址，若镜像未同步对应包，则install时因哈希不匹配报错，需同步清除vendor与composer.lock并切回官方源重装生成新锁文件。
composer.lock 的哈希值不随镜像切换而改变
镜像源（如 https://mirrors.aliyun.com/composer/）只影响元数据拉取路径和 dist 包下载地址，composer.lock 文件里的 dist.sha256 值始终来自 Packagist 官方快照——哪怕你全程用阿里云镜像，lock 文件里记录的哈希也是上游生成的原始值。
常见错误现象：
- 切了镜像后
composer install报hash verification failed→ 实际是镜像未同步该包的 dist 文件，而非 lock 文件“错了” - 本地
composer.lock显示"dist": {"sha256": "abc123..."}，但阿里云返回的 zip 解压后算出来是def456...→ 镜像缓存滞后，不是 lock 有问题
实操建议：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer config -g repos.packagist输出必须是镜像 URL，否则请求根本没走镜像站 - 手动验证镜像是否真同步：
curl -s https://mirrors.aliyun.com/composer/p2/vendor/name/version.json | jq .packages，对比https://packagist.org/p2/...是否一致 - 不要编辑
composer.lock里的dist.sha256字段——它不是配置项，是二进制快照的一部分，改一个字符就导致composer install拒绝执行
镜像滞后时，旧 lock 文件必然校验失败
阿里云、腾讯云等镜像通常有 10–30 分钟同步延迟，尤其对新 tag 或 dev 分支。此时若项目仍保留旧 composer.lock，composer install 就会拿 lock 里记录的哈希去比对镜像返回的（尚未更新的）旧包，必然不匹配。
为什么不能“换镜像 + 删 vendor + 重 install”？
- 删
vendor/不影响composer.lock，install 仍复用旧哈希校验 - 镜像源切换后，
packages.json和provider-*.json分片可能未全量同步，导致部分包元数据缺失，Composer 卡在 404 而非报错 - 某些镜像不支持 p2 协议（如老旧私有代理），请求
/p2/...直接 404，Composer 不 fallback，安装中断
实操建议：
- 遇到
hash verification failed，第一反应不是换镜像，而是清双：rm -rf vendor composer.lock - 先切回官方源：
composer config -g --unset repos.packagist，再composer install生成新 lock - 确认新 lock 生效后再切回镜像：
composer config -g repos.packagist composer https://mirrors.aliyun.com/composer/
verify-checksums 命令不依赖镜像源，只读 lock 文件
COMPOSER_EXPERIMENTAL=1 composer verify-checksums --strict 这个命令的行为与当前配置的镜像无关——它只读 composer.lock 里的 dist.sha256，然后重新计算本地 vendor/{package}/ 目录的实际哈希值。
这意味着：
- 即使你用的是华为云镜像，只要
composer.lock是从 Packagist 官方生成的，校验就按官方哈希比 - 如果镜像返回的 dist 包内容与 Packagist 不一致（比如打了补丁但没更新 sha256），
verify-checksums必然失败——这不是 bug，是安全机制在起作用 - 它不校验
"type": "path"或"type": "vcs"的包，只针对 dist 安装方式生成的目录
注意陷阱：
- 运行前必须确保
vendor/已存在且composer.lock是最新生成的（即刚跑完composer install） - CI 流程中务必加
--strict，否则校验失败也不会中断构建 - 别指望它帮你发现镜像不同步问题——它只告诉你“现在装的包和 lock 承诺的不一样”，不告诉你原因
真正卡住部署的，是 lock 文件、镜像、Composer 版本三者没对齐
一个看似简单的 composer install 失败，往往不是单一环节的问题。比如：
- 项目用了 Composer 2.9.6，但
composer.lock是用 2.5 生成的，缺少content-hash字段 → 新版校验逻辑更严，直接拒绝 - 镜像支持 p2 协议，但本地 Composer 版本低于 2.2，仍发
/p/provider-xxx.json请求 → 镜像返回 404，卡死 - CI 环境 PHP 版本是 8.3，但
composer.lock里platform.php写的是8.1→dist.sha256对应的是为 8.1 编译的扩展，加载失败
最容易被忽略的点：
-
composer.lock不是“一次生成，永久有效”，它绑定的是生成时刻的元数据快照、PHP 平台约束、Composer 版本行为 - Git 提交时若被编辑器自动删了 trailing comma，JSON 解析不全，
platform字段丢失 → 构建时报incompatible with your PHP version - Windows 用户用记事本保存
composer.lock，触发 CRLF 换行 →composer validate --strict直接失败
