composer global remove 是卸载全局命令行工具的唯一标准方式，它同步移除依赖声明、删除对应目录并重建 autoload.php，手动删文件会导致 Composer 状态不一致。
composer global remove 是卸载全局命令行工具的唯一标准方式
直接运行 composer global remove vendor/package-name 就能干净卸载像 laravel/installer、phpunit/phpunit 这类全局命令行工具。它不是“删文件”那么简单——这条命令会同步三件事：从 ~/.composer/composer.json 中移除依赖声明、删除 ~/.composer/vendor/vendor/package-name 对应目录、自动重建 ~/.composer/vendor/autoload.php。跳过它而手动删文件，会导致 Composer 认为包还在，下次 global update 可能出错或重装。
卸载后命令还能执行？那是 ~/.composer/vendor/bin 的残留二进制没清掉
常见现象：运行 composer global remove laravel/installer 后，laravel --version 依然可用。这不是卸载失败，而是可执行文件还留在 ~/.composer/vendor/bin/ 目录里，而该路径通常在你的 PATH 环境变量中。
- 手动清理对应二进制：
rm ~/.composer/vendor/bin/laravel - 确认是否还有其他残留：
ls ~/.composer/vendor/bin/ - 检查 PATH 是否包含该路径：
echo $PATH | grep composer
windows 用户对应路径是 %appDATA%Composervendorbin，需在资源管理器中开启“显示隐藏的项目”才能看到。
别在项目目录里误用 global 命令
composer global 操作的是用户级环境（~/.composer），和当前 PHP 项目完全无关。如果在某个 Laravel 项目的根目录下运行 composer global remove foo/bar，它照样生效；但如果你手快漏了 global，写成 composer remove foo/bar，就会去改当前项目的 composer.json 和 vendor/ —— 这不是卸载全局工具，是破坏项目依赖。
- 永远先确认你在“全局上下文”：运行
composer global show能列出包，才说明你处在正确的操作域 - 不确定时，加
--dry-run（部分旧版不支持）或先用composer global config --list看配置是否指向~/.composer - linux/macOS 下，
which composer返回/usr/local/bin/composer是正常；返回./composer或项目内路径，则说明当前 shell 正在调用本地副本，可能干扰判断
彻底清空所有全局包的两种安全做法
想一键归零？别用 rm -rf ~/.composer/vendor 后就不管了——虽然物理上删掉了代码，但 ~/.composer/composer.json 里还留着已卸载包的记录，下次 global install 可能触发冲突或警告。
- 推荐方式：逐个卸载 + 清缓存
composer global remove $(composer global show --name-only | xargs)（注意：需 shell 支持命令替换，zsh/bash 可用，fish 需调整）
- 更稳妥方式：删 vendor 目录 + 重置 composer.json
rm -rf ~/.composer/vendor
sed -i '/"require": {/,/}/c "require": []' ~/.composer/composer.json（Linux/macOS；Windows 请用 PowerShell 替代 sed）
- 最后别忘清理缓存：
composer clear-cache
最常被忽略的点是：即使删光了所有包，~/.composer/vendor/bin/ 下的符号链接或硬链接仍可能残留，它们不会随 vendor 目录一起消失，必须单独处理。