composer global update 经常没反应，因为它只依据 ~/.composer/composer.json 的版本约束更新，而该文件通常不存在或版本号过时过严（如 "laravel/installer": "^4.0"），导致无法拉取 v5.x；执行后静默退出、laravel --version 仍为旧版即属此因。
别用 composer global update —— 它大概率静默失败，且不更新你真正想升的包。
为什么 composer global update 总是没反应
它只读取 ~/.composer/composer.json 里的版本约束去更新，而这个文件经常根本不存在，或者里面锁着过时、过严的版本（比如 "laravel/installer": "^4.0"），导致连 v5.x 都拉不到。执行后无输出、laravel --version 还是旧版，就是典型表现。
常见错误现象：
-
ls ~/.composer/composer.json返回No such file -
composer global show laravel/installer显示已装4.4.0，但composer global show laravel/installer --all明明有5.12.0标了latest - 执行
composer global update后，which laravel路径没变，但命令报command not found
安全更新单个全局 CLI 工具的实操步骤
核心思路：显式重装，而非依赖自动更新。以升级 laravel/installer 为例：
- 查当前版本：
laravel --version或composer global show laravel/installer - 查最新稳定版：
composer global show laravel/installer --all | grep latest - 显式重装指定版本：
composer global require laravel/installer:^5.0 - 验证是否生效：
which laravel应输出$HOME/.composer/vendor/bin/laravel
注意：composer global require 在已存在该包时，行为等价于局部更新 + 可能追加依赖，比 update 更可控；但不要加不存在的参数如 --update-with-dependencies（Composer 源码里没有这个选项，会报 Unknown option）。
PATH 和 bin-dir 失效怎么办
即使 composer global require 成功，laravel 命令仍可能找不到——问题不在安装，而在 shell 找不到二进制路径。
- 确认
~/.composer/vendor/bin/是否在$PATH中：echo $PATH | grep -o "$HOME/.composer/vendor/bin" - 若无输出，补进 shell 配置（如
~/.zshrc）：export PATH="$HOME/.composer/vendor/bin:$PATH" - 重载配置：
source ~/.zshrc - 验证：
which laravel必须有输出，且直接运行laravel --version要能返回新版本号
composer global list 只显示注册的命令名，不校验可执行性，不能代替 which 或实际运行测试。
要不要批量更新所有全局包
不建议。全局包来源杂、维护节奏不一、依赖约束常互相打架——比如 phpunit/phpunit 升到 v10 要 PHP 8.1+，而你装的 deployer/deployer v7 还卡在 symfony/console ^4.0，硬跑 composer global update 会直接报 Your requirements could not be resolved，且不提示具体哪个包冲突。
更现实的做法：
- 先列出现有包：
composer global show --direct（只看直接安装的，排除干扰） - 对每个包单独判断：
composer global show vendor/package --all看是否有新版、是否兼容当前 PHP 版本 - 长期未维护或已有 PHAR 分发的包（如
phpstan/phpstan），优先卸载：composer global remove vendor/package
真正容易被忽略的一点：全局包不是“装一次就不管”，而是需要定期逐个审视其必要性和兼容性——因为 Composer 不替你做这个决策，它只按你给的约束执行。
