Composer无内置global update批量命令，直接运行易因依赖冲突或PHP版本不兼容报错；应逐个检查、显式require更新，优先项目内安装，避免全局维护负担。
Composer 没有内置的 global update 批量更新命令，直接运行 composer global update 会尝试更新所有全局包，但极易失败——尤其当包之间存在冲突依赖或 PHP 版本不兼容时。
为什么 composer global update 经常报错
全局包通常来自不同作者、维护节奏不一，composer.json 中的约束（如 "php": "^8.0" 或 "laravel/installer": "^4.0"）可能互相矛盾。Composer 在解析依赖图时一旦发现无法满足所有要求，就会抛出 Your requirements could not be resolved 错误，且不提示具体是哪个包导致的。
- 常见错误信息包含：
Root composer.json requires ... but ... is installed - PHP 版本不匹配（例如某包已放弃对 PHP 8.1 的支持，而你本地是 8.2）
- 某些包长期未维护，其依赖的旧版
symfony/console与新装的phpunit冲突
安全更新全局包的正确做法：逐个确认 + 显式指定版本
不要依赖一次性全量更新。应先查看当前安装了哪些包，再针对性升级可维护、有新版且兼容当前环境的包。
- 列出所有全局包：
composer global list或composer global show - 对每个想更新的包，查它的最新稳定版：
composer global show vendor/package-name（看 latest 版本号） - 显式执行更新：
composer global require vendor/package-name:^5.0（用require而非update，避免牵连其他包） - 如果要降级或回退，用
composer global require vendor/package-name:4.3.2（精确版本）
如何判断某个全局包是否还值得保留
很多全局包（如 laravel/installer、phpunit/phpunit、deployer/deployer）已转向项目级安装或提供 PHAR 分发，继续全局安装反而增加维护负担。
- 检查该包是否在项目中也需使用：如果是，优先改用
composer require --dev项目内安装 - 查看包仓库的 README：如
phpstan/phpstan官方明确建议“不要全局安装” - 运行
which package-name（如which phpunit），确认路径是否为~/.composer/vendor/bin/；若多年未更新且无新 issue，建议卸载：composer global remove vendor/package-name
临时绕过冲突强制更新（仅限调试，不推荐生产）
极少数场景下需快速验证某包行为，可跳过依赖检查（但后果自负）：
composer global update --ignore-platform-reqs --no-interaction
这会忽略 PHP 版本、扩展等平台约束，也可能装上根本无法运行的二进制文件。执行后务必手动测试命令是否可用，例如：
phpunit --version
若报 Class not found 或 undefined function，说明依赖损坏，应立即 composer global remove 并换回稳定版本。
真正麻烦的不是命令怎么敲，而是每个全局包背后都可能绑着一套独立的依赖树和生命周期——没人替你协调它们之间的关系。宁可多敲几行 require，也别信“一键更新”。
