composer update 仅按 composer.json 约束升级，不跳主版本；用 outdated 查可升包，–dry-run 预演效果；升主版本须手动改约束并逐个更新验证。
composer update 并不是“一键升到最新版”
它只按 composer.json 里的版本约束升级，比如 "guzzlehttp/guzzle": "^7.0" 永远不会升到 8.x，哪怕 8.5.0 已发布。这不是 bug，是语义化版本（SemVer）的保护机制——防止意外主版本破坏兼容性。
- 想看哪些包其实能升：运行
composer outdated，它只列信息，不改任何文件 - 想预演升级效果：加
--dry-run，例如composer update --dry-run，输出里会标出所有将被更新的包和版本号 - 别直接
composer update全量升级线上项目，尤其含laravel、symfony或自定义封装包时，一个doctrine/dbal升级就可能让迁移命令报Unknown database type json
真要升到最新主版本，必须手动改约束再更新
没有“跳过约束强制全升”的安全命令。强行删 composer.lock + rm -rf vendor + composer install 看似能重装最新匹配版，但结果不可控——composer install 仍受 composer.json 限制，且可能因依赖树冲突失败，报错如 Your requirements could not be resolved。
- 安全做法：逐个处理，比如想升
monolog/monolog到 v3，先改composer.json为"monolog/monolog": "^3.0"，再运行composer update monolog/monolog --with-dependencies - 批量改约束？别用
*或dev-main，它们会让 CI 构建不稳定；更别全局替换"^1.2"→"^2.0"，很多包 v2 和 v1 的接口已不兼容 - 升级后立刻验证：运行
composer dump-autoload -o重生成自动加载，Laravel 项目还要跑php artisan config:clear和php artisan cache:clear，否则常出现配置没刷新、类找不到等“假报错”
全局包不能用 project 方式更新
composer global update 表面看是“批量更新”，但它会读取 ~/.composer/composer.json，而这个文件往往多年没人维护，里面一堆 ^1.0 或 ~2.5 老约束，一跑就卡在平台要求上，比如报 phpunit/phpunit 9.6 requires php >=7.3，而你 CLI 是 PHP 8.2 —— 它不提示，直接停住。
- 正确姿势：先
composer global show --direct列出真正需要的包，再一个个确认是否还值得留（比如laravel/installer现在推荐项目内composer require --dev laravel/installer） - 升级单个：用
composer global require vendor/package-name:^5.0，require比update更干净，不牵连其他包 - 发现某全局包路径是
/usr/local/bin/phpunit而不是~/.composer/vendor/bin/phpunit？说明它可能是系统级安装或 PHAR，别碰composer global，直接卸载重装
升级前必须核对三件事，缺一不可
很多人跳过这步，结果在测试环境跑通，上线后 PHP Fatal Error：class ‘SymfonyComponentHttpKernelKernel’ not found，因为 symfony/framework-bundle 升了 v6，但 php -v 是 8.0，而 v6 要求 PHP 8.1+。
- 运行
php -v和composer validate，后者会检查composer.json里写的"php": "^8.1"是否匹配当前 CLI 版本 - 打开
composer.lock，搜"platform"字段，确认它记录的 PHP、扩展版本与部署机一致 - 查安全风险：
composer audit（需 Composer 2.5+），它会调用 Packagist 的漏洞数据库，比人工翻 github Security Advisories 快得多
复杂点不在命令多难记，而在每个包的升级路径都不同——有的要改配置，有的要删缓存，有的得同步升级配套插件。没验证就批量动，等于把依赖树当骰子摇。