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\ven

dor\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、删完验证命令是否真消失——三步缺一不可。