Composer安装失败需逐层清理：先用which/where确认安装方式，再删除主文件、~/.composer、缓存目录（~/.cache/composer等）、XDG配置（~/.config/composer），并清除shell别名、hash缓存及PATH引用，最后新开终端验证command -v composer无输出。
Composer安装后残留的不只是composer命令本身，而是分散在文件系统、shell环境、缓存机制里的多层“影子”——不逐层清理，重装大概率失败或行为异常。
怎么确认 Composer 是哪种方式装的
盲目删文件等于埋雷。先搞清来源，再决定动哪些路径：
- 运行
which composer（Linux/macOS）或where composer（Windows），看输出：/usr/local/bin/composer→ 手动安装；/opt/homebrew/bin/composer→ brew 安装；C:\ProgramData\ComposerSetup\bin\composer.bat→ Windows 官方安装器 - Linux 上查包管理状态：
dpkg -l | grep composer（Debian/Ubuntu）或rpm -qa | grep composer（RHEL/CentOS） - macOS 上查：
brew list | grep composer；如果存在，必须用brew uninstall composer卸载，不能直接删二进制 - 若
composer --version报错但which composer有输出，说明 PATH 或 hash 缓存还在，但主文件可能已失效
手动安装残留必须清的四个路径
如果你是用curl -sS https://getcomposer.org/installer | php或下载composer.phar安装的，以下目录一个都不能漏：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
sudo rm $(which composer)—— 主命令文件，常见于/usr/local/bin/composer或~/bin/composer -
rm -rf ~/.composer—— 用户级配置、全局包（如laravel/installer）、插件、auth凭证全在这里 -
rm -rf ~/.cache/composer（Linux）或rm -rf ~/Library/Caches/composer（macOS）或%LOCALAPPDATA%\Composer\Cache（Windows）—— 独立缓存目录，composer clear-cache只清这里，但安装失败时它常含损坏文件 -
rm -rf ~/.config/composer—— XDG 规范下生成的配置目录，部分 zsh + oh-my-zsh 用户会意外创建，不删会导致新安装读到旧 config
shell 层的“幽灵引用”最容易被忽略
即使所有文件都删光，终端仍可能“假装认识”composer：
- 运行
type composer：若返回composer is aliased to或composer is a function，检查~/.bashrc、~/.zshrc、~/.profile中是否有alias composer=或函数定义，手动删掉 - 运行
hash -d composer（Bash/Zsh）清除命令哈希缓存 - PATH 中可能还挂着旧路径，比如
export PATH="/old/path/to/composer:$PATH"，搜grep -r "composer" ~/.bash* ~/.zsh*定位并清理 - 最后新开终端，执行
command -v composer和which composer，两者都应无输出
缓存清理 ≠ 重装成功，关键在 repo/ 子目录是否被动过
composer clear-cache默认清空~/.composer/cache下的files/、vcs/、repo/三个子目录，但实际影响差异很大：
-
files/：存 ZIP/TAR 包，占空间最大，删它释放磁盘最明显 -
vcs/：Git 克隆的裸仓库，可安全全删，下次需要自动重建 -
repo/packagist.org/：核心元数据快照，删了会导致首次composer update变慢（要重新 fetch），不是 bug，是设计如此 - CI/CD 中必须加
--no-interaction，否则composer clear-cache会在非交互环境下卡住 - 如果改过
COMPOSER_CACHE_DIR环境变量，clear-cache只清那个路径，不会管默认位置
真正容易被跳过的点：私有仓库配置（比如repositories写在全局config.json里）会让清完缓存后的首次请求变慢——因为元数据必须重新拉取，且无法走本地缓存。
