composer global update 经常没反应是因为它只依据 ~/.composer/composer.json 的版本约束更新，而该文件通常不存在或版本号过时过严；执行后静默退出、版本不变即属此因。
composer global update 为什么经常没反应？
因为 composer global update 不是“一键升级所有已装工具”的开关，它只按 ~/.composer/composer.json 里的版本约束去更新——而这个文件往往根本不存在，或者只含过时、过严的版本号（比如 "laravel/installer": "^4.0"），根本拉不到 v5.x。
常见错误现象：composer global update 执行后静默退出、无输出、laravel --version 仍是旧版。
- 先确认文件是否存在：
ls ~/.composer/composer.json，大概率返回 “No such file” - 别指望它自动发现你装过什么；
composer global show才是你该看的第一眼 - 如果真有
composer.json，用cat ~/.composer/composer.json检查版本字段是否宽松（如"^5.0"或"*"）
怎么安全地更新一个全局 CLI 工具？
推荐做法是显式重装，而不是依赖 global update 碰运气。以升级 laravel/installer 为例：
- 查当前版本：
laravel --version或composer global show laravel/installer - 查最新稳定版：
composer global show laravel/installer --all（看 latest 标记） - 重装指定版本：
composer global require laravel/installer:^5.0 --update-with-dependencies
加 --update-with-dependencies 很关键：否则可能只升主包，留下冲突的旧依赖（比如新 laravel/installer 要 symfony/console ^6.0，但旧 phpunit 还锁着 ^5.4）。
PATH 和 bin-dir 失效，更新后命令还是找不到
即使 composer global require 成功执行，你也可能遇到 command not found: laravel——问题不在安装，而在系统找不到二进制文件。
- 确认
~/.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应输出/home/xxx/.composer/vendor/bin/laravel
注意：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 outdated，它只告诉你哪些能升，不改任何东西 - 真要批量操作，先生成基础清单：
composer global show --format=json > ~/.composer/composer.json，再手动编辑每个包的版本为宽松约束 - 更务实的选择：把常用工具（如
phpstan、phpcs）改用项目内安装：composer require --dev phpstan/phpstan，避免全局环境越来越难收拾
真正麻烦的从来不是“怎么升”，而是升完之后某个脚本突然挂了，却想不起是哪个包悄悄变了行为——所以每次更新，最好都配一句 laravel new test-app && cd test-app && laravel --version 这样的快速验证。
