composer update 按语义化版本约束安全升级依赖，不跨主版本；需手动改 composer.json 才升主版本，推荐先用 outdated 检查、--dry-run 预演、audit 查漏洞，并验证 autoload 与缓存。
composer update 会升级所有包，但默认不升主版本
执行 composer update 确实会更新 composer.json 中声明的所有依赖到满足版本约束的最新可用版本，但它遵循语义化版本规则：比如 "monolog/monolog": "^2.0" 只会升到 2.x 最新版，不会跳到 3.0。这不是“一键全升”，而是“按约束安全升”。
- 想强制升级到最新主版本（如从 v2 → v3），需手动修改
composer.json中对应包的版本号，再运行composer update vendor/package-name - 直接
composer update同时更新几十个包，容易因兼容性问题导致测试失败或运行时错误 -
composer outdated是更安全的起点——它只列出可升级项及当前/推荐版本，不改动任何文件
升级前必须检查 composer.lock 和 PHP 版本兼容性
忽略 composer.lock 直接 update，可能让团队其他成员拉取不一致的依赖树；而 PHP 版本不匹配则常引发 Your requirements could not be resolved 错误。
- 运行
composer validate确认composer.json格式合法、PHP 版本声明（"php": "^8.1"）与当前环境一致 - 用
php -v核对 CLI PHP 版本，某些包（如symfony/consolev6+）已要求 PHP 8.1+ - 若项目长期未更新，先执行
composer update --dry-run预演，看哪些包会被升级、有无冲突
按需升级比全量 update 更可控
多数线上项目不需要所有依赖都升到最新版，尤其框架核心包（如 Laravel、Symfony）升级需配套改代码。应优先升级有安全修复的包，或明确需要的新特性所依赖的子包。
- 查安全通告：运行
composer audit（需 Composer 2.5+）或访问 https://www.php.cn/link/418140029d08ec9365aebdc9542616a0 对照 - 只升某一个包：
composer update doctrine/dbal，它会自动处理该包及其子依赖的兼容版本 - 锁定次要版本升级（防意外主版本跳变）：
composer update --minor-only（Composer 2.4+）
升级后务必验证 autoload 和缓存
Composer 升级后常见问题不是代码报错，而是自动加载失效或配置缓存未刷新——尤其在 Laravel、Symfony 等框架中。
- 强制重生成自动加载：
composer dump-autoload -o（-o表示优化，生成静态映射） - Laravel 项目记得清配置缓存：
php artisan config:clear和php artisan cache:clear - 如果用了
composer install部署，确保 CI/CD 流程中composer.lock已提交，且部署机执行的是install而非update
composer outdated --direct # 只显示你直接 require 的包（非传递依赖），便于聚焦决策
真正危险的不是“没升级”，而是“没验证升级后的行为”。哪怕只升了一个小版本的 guzzlehttp/guzzle，也可能让 HTTP 请求头默认行为改变，而日志里根本看不出异常。
