composer global update 经常没反应，因为它只依据 ~/.composer/composer.json 中声明的包和版本约束更新，而该文件通常不存在、为空或约束过严（如 "laravel/installer": "^4.0"），导致无法拉取新版；它不扫描已安装包，也不读取 ~/.composer/vendor/ 实际内容。
composer global update 为什么经常没反应
它不扫描你装过什么，也不读取 ~/.composer/vendor/ 下实际存在的包，只认 ~/.composer/composer.json 里声明的包和版本约束。常见情况包括：
-
ls ~/.composer/composer.json返回No such file—— 文件根本不存在 - 文件存在但内容是
"laravel/installer": "^4.0"—— 新版^5.0被锁死，拉不到 -
composer global status报No composer.json found—— 它连入口都找不到
执行后静默退出、laravel --version 没变，基本就是这个原因。
怎么安全地更新一个全局 CLI 工具（比如 laravel/installer）
显式重装比依赖 global update 更可控，也避免依赖冲突。操作顺序不能乱：
- 查当前版本：
laravel --version或composer global show laravel/installer - 查最新稳定版：
composer global show laravel/installer --all | grep latest - 重装指定版本：
composer global require laravel/installer:^5.0 --update-with-dependencies
--update-with-dependencies 很关键：否则主包升了，旧依赖（比如 symfony/console v5）还卡着，运行时报错。
PATH 和 bin-dir 失效，更新后命令还是找不到
安装成功 ≠ 命令可用。composer global require 只把二进制文件放进 ~/.composer/vendor/bin/，系统得知道去哪找它：
- 确认路径是否在
PATH中：echo $PATH | grep -o "$HOME/.composer/vendor/bin"（macOS/Linux） - 没输出？补进 shell 配置：
echo 'export PATH="$HOME/.composer/vendor/bin:$PATH"' >> ~/.zshrc（zsh 用户） - 重载配置：
source ~/.zshrc - 验证生效：
which laravel应输出/home/xxx/.composer/vendor/bin/laravel
composer global list 只说明包注册了，不校验命令是否存在或可执行；which 或直接运行才是真实测试。
要不要批量更新所有全局包
不建议。全局包来源杂、维护节奏不一、依赖约束常互相打架——比如 phpunit/phpunit 升到 v10 要 PHP 8.1+，而你装的 deployer/deployer 还卡在 symfony/console ^4.0，硬跑 composer global update 极易报 Your requirements could not be resolved。
真要批量操作，先用 composer global outdated 看哪些能升，再逐个 require；或者生成基础清单：composer global show --format=json > ~/.composer/composer.json，手动改宽松约束（如 "*"），最后再跑 update。
最常被忽略的其实是 ~/.composer/vendor/bin/ 是否在 PATH 里——哪怕重装十次，路径没配对，command not found 就一直跟着你。
