composer global remove 报“Package not found”是因为全局 composer.json 缺失元信息；应先用 composer global show 确认存在，否则需手动删除 ~/.composer/vendor/ 下包目录及 autoload_*.php，再执行 dump-autoload，并清理 bin 目录中的可执行文件。
composer global remove 会报错“Package not found”
直接运行 composer global remove vendor/package 很可能失败，因为 Composer 全局安装的包实际存放在 ~/.composer/vendor/（Linux/macOS）或 %APPDATA%\Composer\vendor\（Windows），但 global remove 命令依赖 composer.json 中的记录——而全局 composer.json 不一定包含你手动安装过的包（尤其是用 global require 之后又删过文件、或用 --no-scripts 安装的情况）。
- 先确认包是否真在全局列表里：
composer global show - 如果没列出来，说明 Composer 已“丢失”该包的元信息，不能靠
remove清理 - 若显示了，再执行
composer global remove vendor/package，它会删vendor/下对应目录 + 更新composer.json和autoload_static.php
手动删 vendor 目录 + 清 autoload 是最稳妥的方式
当 global remove 失效或你想彻底清理残留时，必须进文件系统操作。注意：别只删 vendor/vendor/package，还要处理自动加载缓存，否则 composer global dump-autoload 可能仍报找不到类。
- 查全局路径：
composer global config home（输出类似/home/user/.composer） - 进
vendor/目录，删对应包文件夹，例如删laravel/installer就删vendor/laravel/installer - 删
vendor/autoload_*.php（如autoload_static.php、autoload_classmap.php），这些是旧映射缓存 - 最后运行
composer global dump-autoload重建自动加载
卸载后命令还存在？检查 $PATH 和 bin 目录
即使删了包，终端仍可能识别 laravel 或 phpunit 这类命令，因为 Composer 把可执行文件软链到了 ~/.composer/vendor/bin/（或 Windows 的 %APPDATA%\Composer\vendor\bin）。这个目录通常被加进了系统 $PATH，所以命令“还在”。
- 运行
which laravel（macOS/Linux）或where laravel（Windows）看命令真实路径 - 如果指向
~/.composer/vendor/bin/laravel，那就直接删那个文件（它是 shell 脚本或 bat 文件） - 删完建议清下 shell 缓存：
hash -d laravel（bash/zsh）或重启终端
避免未来混乱：用 --no-dev 和固定版本号安装全局包
全局包一旦装乱，排查成本高。不是所有包都适合全局安装；而且默认 composer global require vendor/package 会装最新版（可能含 breaking change），且带 dev 依赖（增大体积、引入冲突风险）。
- 明确指定稳定版本：
composer global require laravel/installer:^4.5 - 加
--no-dev跳过开发依赖：composer global require phpunit/phpunit --no-dev - 定期清理：
composer global outdated查过期包，composer global update谨慎更新（最好逐个指定）
全局包管理不像项目内依赖有锁文件约束，删不干净、命令残留、autoload 错乱是常态。关键不是“怎么删”，而是删前确认路径、删后重建 autoload、删完验证命令是否真消失——三步缺一不可。
