Composer不更新旧包是因版本约束、composer.lock锁定及依赖冲突共同作用的结果；需检查lock文件状态、其他包的间接约束及PHP环境兼容性。
Composer 不更新旧包，不是它“懒”或“卡住”，而是你写的约束 + 当前 composer.lock 状态 + 依赖图共同决定的必然结果。它没做错，只是你没看清哪一层在起作用。
为什么 composer update 没装新版本？查这三处
你以为改了 composer.json 里的 "monolog/monolog": "^2.8.0" 就该升到 2.9.0，但实际可能纹丝不动——原因通常就藏在这三个地方：
-
composer.lock文件存在且未提交：只要它在，composer install和composer update都会优先复用其中记录的版本；改了composer.json不运行composer update monolog/monolog，等于白改 - 其他包间接锁死了这个版本：比如
package-a要求monolog/monolog: "^2.8"，而package-b要求monolog/monolog: "^2.9"，Composer 最终只能选一个交集（如2.9.1）；但如果package-b实际只发了2.8.5，那2.9.x就根本不存在，monolog就永远卡在2.8.5 -
config.platform.php或环境 PHP 版本太低：你本地是 PHP 7.4，但monolog 2.9.0声明要php: "^8.0"，Composer 就会跳过它，回退到最后一个兼容的2.8.1
composer update 升级失败却没报错？那是约束被覆盖了
最隐蔽的问题是：你写的约束根本没生效。常见覆盖源有：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
require-dev里写了更激进的版本，比如"phpunit/phpunit": "^10.0"，而主require中某个包只兼容 PHPUnit 9，Composer 为保全局一致，只能把monolog也压回旧版 - 用了
--with-all-dependencies却没加具体包名：它会尝试升级所有间接依赖，可能触发一连串回退，最终反而让目标包更旧 - 私有 Git 包写成了
"vendor/pkg": "dev-main"：每次update都拉最新 commit，但若作者重写了main分支历史，Composer 可能因哈希不匹配而放弃升级，退回已知可用的旧 tag
想强制更新又怕崩？别直接 composer update
盲目全量更新风险高，尤其老项目。稳妥做法是分步控制：
- 先确认当前装的是什么：
composer show monolog/monolog -i，别只信composer.json - 查谁在拖后腿：
composer prohibits monolog/monolog，看哪个包在要求更低版本 - 只更新目标包及其直系依赖：
composer update monolog/monolog --with-dependencies，避免波及psr/log这类基础包 - 如果必须降级（比如已误升到 3.x）：
composer require monolog/monolog:^2.8 --no-update && composer update monolog/monolog，--no-update是关键，否则require只改 JSON 不触发重解
真正决定装哪个版本的，从来不是你“想写什么”，而是 composer.lock 里记了什么、其他包声明了什么、以及你的 PHP 环境允许什么——这三个条件缺一不可。漏掉任何一个，约束就只是摆设。
