卸载 Composer 需删除 composer 文件、PHAR 原文件、PATH 中相关路径及 ~/.composer 目录，并验证 command not found、which 无输出、~/.composer 不存在。
卸载 Composer 本体：删文件比删包更可靠
Composer 不是系统级安装的软件，没有“卸载程序”，它本质就是一个 composer.phar 文件 + 可选的全局命令别名。很多人用 apt remove composer 或 brew uninstall composer，结果发现 composer --version 还在响——因为这些包管理器装的只是个包装脚本，真身早被手动下载过。
- 检查真实位置：
which composer（常见输出如/usr/local/bin/composer或/home/username/.local/bin/composer） - 删除该文件：
rm $(which composer) - 同时删掉可能存在的 PHAR 原文件：
rm /usr/local/bin/composer.phar（如果存在） - 如果是用
curl -sS <a href="https://www.php.cn/link/e910517884e11c8a741c3b1da823f47e">https://www.php.cn/link/e910517884e11c8a741c3b1da823f47e</a> | php手动装的，还要确认当前目录下有没有残留的composer.phar，顺手删掉
清理环境变量 PATH：别让旧路径偷偷生效
即使删了 composer 文件，只要 PATH 里还留着指向它的目录，终端一重启就可能报 command not found 或更诡异的“找不到 autoload”——因为 shell 还在尝试从已删除路径加载。
- 查看哪些文件写了 PATH：
grep -n "composer|bin" ~/.bashrc ~/.zshrc ~/.profile ~/.bash_profile 2>/dev/null - 常见污染行示例：
export PATH="$HOME/.composer/vendor/bin:$PATH"或export PATH="/usr/local/bin:$PATH"（而 /usr/local/bin 下曾放 composer） - 编辑对应文件，删掉整行或注释掉（加
#开头），然后运行source ~/.zshrc（或对应 shell 配置文件） - 验证是否清干净：
echo $PATH里不应再出现含composer或可疑bin路径的片段
删掉全局 vendor 和配置：避免下次重装踩坑
~/.composer/ 是 Composer 的家目录，存着全局依赖、缓存、auth.json、config.json。不删它，重装后可能沿用旧 token、旧镜像源、甚至冲突的插件版本。
- 直接删整个目录：
rm -rf ~/.composer - 注意：这个操作会清除你配置过的 GitHub token、私有仓库 auth、国内镜像设置（如阿里云、腾讯云镜像）——重装后要重新
composer config -g repo.packagist设置 - 如果用过
composer global require装过工具（比如phpunit/phpunit或laravel/installer），它们也存在~/.composer/vendor/下，一并消失，这是预期行为，不是失误
验证是否真干净：别信 “command not found” 就算完
删完立刻关 terminal 再开一个，跑几条命令交叉验证：
-
composer --version必须报command not found（不是其他错误） -
which composer应该无输出（空行） -
ls -la ~/.composer应报No such file or directory - 如果项目里还有
composer.lock或vendor/，那是项目级内容，和全局卸载无关，不用动
环境变量和 ~/.composer 这两处最容易漏，尤其当机器上混用过 apt、brew、手动下载多种方式时，PATH 里可能藏两个不同路径，删了一个另一个还在起作用。
