根本原因是composer.lock中硬编码的dist.sha256和dist.url与新镜像源不匹配，必须同步删除vendor和composer.lock后执行composer install，才能生成适配当前镜像的新锁文件。
换源后 composer.lock 校验失败、包哈希不匹配、安装报错“lock file is not up to date”，根本原因不是镜像本身，而是旧 lock 文件里记录的元数据（如 package hash、dist URLs）仍指向旧源（packagist.org），而新镜像返回的元数据虽等价但签名不同——Composer 会严格比对，不一致就拒绝安装。
为什么换源后 composer.lock 会出错
Composer 不会自动重写 lock 文件里的 URL 和 hash；它只在 install 或 update 时按当前配置拉取元数据并校验。一旦你从官方源生成了 lock，再切到阿里云镜像，composer install 会发现：
- lock 中某包的 dist.shasum 是基于 packagist.org 的 packages.json 算出的
- 镜像源返回的同版本包元数据中 dist.shasum 相同，但 dist.url 域名变了（https://api.github.com/... → https://mirrors.aliyun.com/...）
- Composer 2.2+ 默认开启 strict URL matching，只要 dist.url 不一致，就报 lock file is not up to date
-
composer.lock不是“可迁移”的快照，它和当前生效的源强绑定 - 即使镜像内容完全同步，URL 字段差异也会触发校验失败
- 手动改
lock文件中的dist.url极易出错，且下次update会被覆盖
必须删掉 vendor 和 composer.lock 再重装
这是唯一可靠解法，不是“多此一举”：
- 运行
rm -rf vendor composer.lock（Linux/macOS）或rd /s/q vendor & del composer.lock（Windows） - 确保已正确配置镜像（用
composer config -g repo.packagist或项目级composer config repo.packagist验证输出） - 执行
composer install -vvv—— 加-vvv才能看到真实请求地址，确认日志中出现mirrors.aliyun.com而非packagist.org - 新生成的
lock文件会完整记录镜像源的dist.url和对应 hash，后续install就不会再报错
CI/CD 或团队协作中如何避免反复出错
关键在于让 lock 文件与镜像源的绑定关系可复现、可审计：
- 禁止提交由本地全局配置生成的
lock文件——不同人配的镜像不同，lockhash 必然不一致 - 所有项目统一使用项目级镜像配置：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/，并提交composer.json到 Git - CI 脚本中显式清缓存：
composer clear-cache，再删vendor和lock，最后composer install - 若需保留部分
dev包但避免干扰，用composer install --no-dev，而非跳过lock清理
最常被忽略的一点：换源命令执行成功 ≠ lock 自动适配。只要 composer.lock 里还残留 packagist.org 的痕迹，哪怕镜像 URL 正确、缓存已清，安装阶段依然会卡在校验环节。动手删文件比调试配置快得多。
