composer update vendor/package-name 默认只升到 composer.json 中版本约束允许的最高兼容版，不升级到突破约束的新主版本；需显式指定如 ^2.0 或 --with-all-dependencies 等选项才能实现目标升级。
composer update 只更新一个包时，必须加版本约束
直接运行 composer update vendor/package-name 不会更新到最新版，而是回退到 composer.json 中已声明的版本范围所允许的最高兼容版本——哪怕你本地 vendor/package-name 是 v1.2.0，而最新稳定版已是 v2.0.0，只要 "vendor/package-name": "^1.0" 写在 require 里，它就绝不会升到 v2。
真正想“升级到可用的最新版”，得显式带上版本号或约束：
-
composer update vendor/package-name:^2.0—— 升级到满足 ^2.0 的最新版（含 2.x 全部小版本） -
composer update vendor/package-name:dev-main—— 切到 main 分支（需仓库支持） -
composer update vendor/package-name --with-all-dependencies—— 连带更新其依赖（否则可能因子依赖冲突失败）
遇到 “Your requirements could not be resolved” 怎么办
这是最常卡住的地方：你指定了新版本，但其他已装包的约束和它不兼容。Composer 默认不会自动调整其他包来让这个更新成立。
此时不能只盯着报错里的冲突包名，要分三步查：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer why-not vendor/package-name:2.0.0，看哪个包在阻止升级 - 检查
composer.json中其他包是否锁死了旧版（比如"monolog/monolog": "1.26.1"这种固定版本） - 确认
vendor/package-name的新版本是否要求 PHP ≥8.1，而你当前是 PHP 8.0 —— 错误信息里往往藏在最后一行，容易被忽略
想跳过 autoload 重生成？不行，但可以提速
composer update 每次都会重建 vendor/autoload.php，没法跳过。不过如果你只是临时测试某个包的行为，又不想影响整个项目 autoload，有两个轻量替代方案：
- 用
composer require vendor/package-name:2.0.0 --no-update先改写composer.json，再手动删掉vendor/vendor/package-name目录，最后composer install—— 这样只装这一个包及其直连依赖 - 开发中可直接
git clone包到vendor/vendor/package-name并composer install，配合"repositories"配置临时替换源，适合调试未发布版本
更新后发现 class not found？检查 autoload 的 scope
有些包（尤其是工具类或命令行包）默认不注册 PSR-4 autoload，只靠 autoload-dev 或 bin 字段提供功能。比如你 composer update phpunit/phpunit 后执行 ./vendor/bin/phpunit 报错，大概率是因为新版本把二进制脚本移到了 bin/ 子目录，而旧的软链接还指向老路径。
解决方法很简单：
- 删掉
vendor/bin/phpunit（或对应脚本），再跑一次composer install - 检查该包的
composer.json里"bin"字段是否变化，有些 v10+ 版本已弃用phpunit脚本，改用phpunit9或统一入口vendor/bin/phpunit重定向逻辑
autoload 本身不报错，但脚本路径失效这种细节，很容易在更新后第一个命令就栽跟头。
