版本不生效主因是 composer.lock 强制锁定旧版，清缓存无效；必须修改 composer.json 约束后 run composer update，或删 lock 文件重装；镜像配置需确认生效且清缓存；CI/CD 需加 --no-cache 或清理 lock/vendor。
版本不生效，90% 不是缓存问题，而是 composer.lock 文件在强制锁定旧版本 —— 清缓存根本没用。
为什么 composer clear-cache 不能更新包版本
缓存只影响“下载过程”，不参与“版本决策”。composer install 完全忽略缓存内容，只按 composer.lock 里记录的精确版本号去还原 vendor。即使你刚发布 v2.5.0、镜像也已同步、缓存里却还空着，只要 lock 文件里写的是 "v2.4.0"，它就坚决装 v2.4.0。
-
composer clear-cache删除的是~/.composer/cache/下的元数据和 zip 包，不影响composer.json或composer.lock - 想让新版本进项目，必须触发 lock 文件更新：改
composer.json约束（如"monolog/monolog": "^3.0"），再跑composer update monolog/monolog - 直接删
composer.lock再composer install也能生效，但会重算整棵树，容易引入意外冲突
composer update 没反应？先看约束有没有变
执行 composer update 后 vendor 无变化，大概率是因为 composer.json 里的版本范围根本没松动。Composer 不会主动“升级到最新版”，它只响应你写的约束变化。
- 例如原写
"laravel/framework": "^10.0"，当前已装 10.42.0；你没改这行，composer update就什么也不做 —— 这是设计，不是 bug - 加
-v参数运行：composer update -v，看输出里是否出现Nothing to install or update，确认是否真被跳过 - 临时测试是否能拉新版：运行
composer show laravel/framework，对比输出的 latest 版本和 lock 文件里记录的版本
换镜像后版本还是旧的？检查 repo.packagist 配置是否生效
国内镜像源（如阿里云）是代理，不是独立仓库。如果 composer config -g repo.packagist 没关掉默认源，Composer 仍会 fallback 到 repo.packagist.org，导致“明明配了镜像却还在走国外地址”。
- 确认配置生效：
composer config -g repo.packagist应输出类似{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 如果输出
false或为空，说明配置未生效，需补上：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 换源后必须清缓存：
composer clear-cache --no-interaction，否则旧的packages.json元数据还在，根本不会请求新镜像
CI/CD 里 composer update 总是装旧版？别漏掉 --no-cache
某些 CI 环境（尤其是复用缓存层的 runner）会把 vendor 或 lock 文件固化，导致每次构建都复现上一次的状态。这时候光清本地缓存没用，得绕过整个缓存链路。
- 加
--no-cache强制跳过所有缓存读取：composer update --no-cache --no-interaction - 更彻底的做法：在 CI 脚本开头加
rm -f composer.lock && rm -rf vendor，再composer install --no-cache --no-interaction - 注意：GitHub Actions 默认不保留
composer.lock，若你用了actions/cache缓存了它，就得在 restore 步骤前加条件判断或设 key 带 hash 变化
真正卡住版本更新的，从来不是缓存目录里那几个 .zip 文件，而是 composer.lock 的锁定逻辑、镜像配置的 fallback 行为、以及 composer.json 里那些看似宽松实则僵硬的版本约束。盯住这三个点，比反复 clear-cache 有效十倍。
