composer clear-cache不能解决版本锁定异常，因其仅清理缓存中的ZIP包和元数据快照，不触及composer.lock、vendor/composer/installed.json及repo元数据目录，而这三者共同决定实际安装版本。
为什么 composer clear-cache 不能解决版本锁定异常
因为 composer clear-cache 只清 ~/.composer/cache/（或 Windows 下 %APPDATA%\Composer\Cache）里的 ZIP 包和元数据快照，但不碰 composer.lock 和 vendor/composer/installed.json——而这两个文件才是“版本锁定”的实际执行者。只要它们还存在，Composer 就会严格按里面写的 SHA256、version、source URL 去匹配缓存或重装，哪怕远程已发布 v3.0.0，它也只认 lock 文件里锁死的 v2.1.7。
必须同步清理的三个关键位置
版本锁定异常（比如 composer update 不拉新包、composer show 显示旧版、私有包更新后仍用旧 commit）本质是本地状态和远程元数据脱节。要真正“解锁”，得一起动这三处：
-
~/.composer/cache/repo/https---packagist.org/：删掉这里，才能让下次update强制重下packages.json和 provider 列表 -
vendor/composer/installed.json：它是当前 vendor 的快照，影响show、outdated输出，不清它，命令就以为“已经是最新” -
composer.lock：不是缓存，但它是版本锁定的源头。不删它，update就只在 lock 约束内找解，根本不会去查远程有没有新版
推荐顺序执行：
composer clear-cache rm -rf ~/.composer/cache/repo/https---packagist.org/ rm -f vendor/composer/installed.json rm -f composer.lock
删完 lock 文件后怎么安全重装
直接 composer install 会失败——因为没 composer.lock，它默认走 require 中的版本约束（如 "^8.0"），可能装出和之前完全不同的依赖树。更可控的做法是：
- 先用
composer update --dry-run -v看它打算装哪些包、是否命中你期望的新版本 - 确认无误后，加
--no-cache强制跳过所有本地缓存，避免复用旧 ZIP 或旧 metadata - 加上
--with-all-dependencies（可选），确保子依赖也一并升级，而不是卡在某个间接依赖的老版本上
示例：
composer update --no-cache --dry-run -v # 确认输出含目标新版本后： composer update --no-cache
容易被忽略的镜像配置陷阱
即使清了所有缓存，如果镜像源没生效，update 日志里依然会出现 Downloading https://packagist.org/...，说明 Composer 还在直连官方源，自然拉不到你私有仓库或国内镜像上的新版包。验证是否生效只需两步：
- 检查配置键名是否为
repo.packagist（不是repos.packagist，多一个s就无效） - 确认 type 值是
composer，且 URL 末尾**没有斜杠**：composer config -g repo.packagist composer https://mirrors.aliyun.com
然后跑 composer update -vvv | grep "Reading packages.json"，看到路径里含 aliyun 或你的私有域名才算真正接管。
