Composer 的环境变量存在哪？删错地方白忙活
Composer 本身不管理全局环境变量，它只读取系统已有的 COMPOSER_HOME、PATH 等变量。你看到的“Composer 环境变量”，大概率是自己手动加的——比如在 ~/.bashrc、~/.zshrc 或 Windows 的系统属性 → 环境变量里追加了 export COMPOSER_HOME="/some/path" 或把 Composer 二进制路径塞进了 PATH。
常见错误现象：composer --version 还能用，但换终端就报 command not found；或者删了 composer.phar，composer 命令居然还在——说明 PATH 里还挂着旧的 alias 或软链接。
- Linux/macOS：搜
grep -n "composer\|COMPOSER" ~/.bashrc ~/.zshrc ~/.profile 2>/dev/null - Windows：打开「系统属性 → 高级 → 环境变量」，检查「用户变量」和「系统变量」里的
PATH和自定义变量 - 删之前先备份：比如
cp ~/.zshrc ~/.zshrc.bak
彻底卸载 Composer 的三个动作缺一不可
Composer 没有“卸载程序”，所谓卸载就是清理三类东西：可执行文件、配置目录、环境引用。漏掉任一环，下次装新版本时都可能复用旧配置或冲突。
- 删二进制文件：
rm /usr/local/bin/composer（全局安装）或rm ~/bin/composer（用户目录），不确定位置就先运行which composer - 删配置与缓存目录：
rm -rf $(composer config -g home 2>/dev/null || echo "$HOME/.composer")（这行能兼容老版本默认路径） - 删环境变量引用：按上一节方法，删掉所有含
composer或COMPOSER的export行，并执行source ~/.zshrc（或对应 shell 文件）刷新
注意：composer config -g home 在已卸载二进制后会失效，所以用 || echo "$HOME/.composer" 做兜底——这是容易被忽略的兼容点。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
Windows 下删不干净？重点查这几个位置
Windows 用户最容易卡在“删了 php/composer 目录，命令还存在”，因为 Composer 常被装成全局 PHAR 并注册进系统 PATH，甚至有些一键 PHP 环境（如 XAMPP、Laragon）会悄悄托管它。
- 查 PATH：
echo %PATH%或图形界面里确认是否包含类似C:\php、C:\Users\XXX\composer的路径 - 查残留 PHAR：
dir /s composer.phar（尤其留意%USERPROFILE%\AppData\Roaming\Composer和C:\ProgramData\ComposerSetup\bin） - 删注册表项（仅限通过 Composer-Setup.exe 安装）：
HKEY_CURRENT_USER\Software\Composer和HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Composer
别信“控制面板卸载程序”列表里没 Composer 就等于干净——90% 的 Composer 是靠命令行安装的，不会出现在那里。
删完验证：别只看 command not found
真正要验证的是“无残留影响”，而不是“命令打不出”。比如旧 COMPOSER_HOME 指向一个不存在的目录，虽然 composer 命令没了，但某些 PHP 脚本或 CI 流程仍可能因该变量异常失败。
- 清空后新开终端，运行
env | grep -i composer（macOS/Linux）或set COMPOSER（Windows），应无输出 - 检查
php --ini加载的配置里有没有composer相关扩展（极少见，但自定义 ini 里可能硬编码过） - 如果项目里用了
composer-plugin，删全局 Composer 不影响项目内vendor/bin/composer，这是预期行为，不是没删干净
最常被忽略的是：删完重装 Composer 时，COMPOSER_HOME 若曾被设为只读路径或 NFS 挂载点，新安装会静默降级到 $HOME/.composer，导致你以为“又回来了”——其实只是换了个地方写。
