composer update 默认只升级符合版本约束的小版本和补丁版本，不会跨主版本升级；如需升主版本须先修改 composer.json 中的版本约束。
composer update 不升级次要版本？默认行为要搞清
默认情况下 composer update 会按 composer.json 中的版本约束（比如 ^2.1.0 或 ~3.4）更新到**符合约束的最新兼容版本**，不是“所有包都升到最高主版本”。它不会把 monolog/monolog 从 2.9.1 升到 3.0.0，除非你显式改了约束或用了强制选项。
- 想升小版本和补丁版（如
2.8.0 → 2.9.2）：直接运行composer update就够了 - 想突破当前约束、允许升主版本（如
2.x → 3.x）：必须先改composer.json里的版本号，比如把"monolog/monolog": "^2.0"改成"^3.0"，再composer update monolog/monolog - 不改约束硬升？
composer update --with-all-dependencies仍受约束限制，不会越界
升级全部包但跳过某些不稳定依赖
有些包（比如开发用的 phpunit/phpunit 或未稳定发布的 dev-master 分支）升级后容易 break 测试或 CI。这时别全量强更，用排除法更稳。
- 保留关键运行时依赖升级，跳过
require-dev下的工具：运行composer update --no-dev - 明确排除某个包：比如不想动
laravel/framework，就执行composer update --with-all-dependencies vendor/package1 vendor/package2，不列它 - 临时锁定某包版本：在命令里加
--prefer-stable，避免拉dev-或alpha版本
升级失败常见报错和对应解法
最常卡在依赖冲突，错误信息像 Your requirements could not be resolved to an installable set of packages. —— 这说明几个包的版本约束互相打架，不是网络或权限问题。
- 先看报错里具体哪两个包冲突（通常有
package-a v1.2 requires package-b ^3.0但package-c v4.0 requires package-b ^4.0这类提示） - 用
composer why-not vendor/package:version查谁在阻止升级 - 临时降级某包约束：比如把
"symfony/console": "^6.0"改成"^5.4 || ^6.0"再试 - 慎用
--ignore-platform-reqs：它绕过 PHP 版本、扩展检查，可能装上根本跑不起来的包
升级后 vendor/autoload.php 失效？autoload 没刷新
升级完如果出现 class not found，大概率不是包没装对，而是 Composer 的自动加载映射没重建。
- 执行
composer dump-autoload强制重生成vendor/autoload.php - 开发中常用
composer dump-autoload -o（优化模式），生成静态映射，性能更好 - 如果项目用了 PSR-4 自定义命名空间，确保
composer.json的autoload段没被升级覆盖或格式损坏 - CI 环境里建议加
composer install --no-dev --optimize-autoloader而非 update，更可控
实际升级前最好 git add composer.json && git commit -m "before composer update"。依赖树一变，回滚靠的是这行提交，不是靠记忆哪个包该锁哪个版本。