根本原因是composer可执行文件路径未加入系统path环境变量或存在冲突；需运行where composer验证路径是否生效、检查是否被旧版bat拦截、确认php.exe存在且版本兼容，并重启终端使配置生效。
composer命令提示“不是内部或外部命令”但安装明明完成了
这根本不是安装失败，而是Windows压根没“看见”它——composer可执行文件路径没进系统PATH，或者进了但被忽略。哪怕你双击Composer-Setup.exe一路点“下一步”，UAC或杀软也可能静默拦截PATH写入，导致安装完成却无法调用。
验证是否真被系统识别，别信弹窗，直接在cmd里运行：
where composer
如果返回空行，说明PATH里没有；如果返回多行（比如同时有C:\OpenServer\modules\php\PHP_8.1\composer.bat和C:\ProgramData\ComposerSetup\bin\composer.bat），说明系统优先调用了旧路径下的bat，新装的被绕过了。
PATH里明明加了路径，为什么还是不生效
常见陷阱不是“没加”，而是加得不对、加得不干净、或加完没刷新到位。重点检查以下几处：
- 路径末尾带反斜杠（如
C:\ProgramData\ComposerSetup\bin\）会导致失效，必须删掉 - 路径中含中文、空格或全角符号（比如“程序文件”被误写成“程序 文件”）会中断解析
- 新增路径没放在Path列表最前面，而前面恰好有XAMPP/WAMP/PhpStorm内置PHP目录，里面也藏着一个
composer.bat，Windows就先执行那个了 - 改完环境变量后没关掉所有终端窗口，旧cmd会继续缓存旧PATH，必须新开一个
- 某些终端（如Windows Terminal、IDE内置终端）会继承启动时的环境变量，即使你重启了cmd，它仍可能用旧值——此时要任务管理器里右键重启“Windows 资源管理器”强制刷新系统级环境
怎么确认composer.bat调用的是正确的php.exe
composer.bat本质是个批处理脚本，第一行类似@php "%~dp0composer.phar" %*，它依赖系统PATH里能找到php.exe。如果PATH里php路径错位、版本太低（php -v低于7.2.5）、或实际指向的是php-win.exe（无控制台输出，bat执行会卡住），composer就会静默失败或报错。
手动验证步骤：
- 运行
php -v，确认输出正常且版本达标 - 打开
composer.bat所在目录（比如C:\ProgramData\ComposerSetup\bin\），检查该目录下是否存在composer.phar - 用记事本打开
composer.bat，确认第一行是@php开头，不是@php-win或@echo打头的无效内容 - 临时在bat里加一行
pause，再运行composer --version，看是否卡在某步——能帮你定位是php找不到，还是phar加载失败
验证PATH是否真正生效的交叉检查法
单靠echo %PATH%或composer --version容易误判。必须用组合命令交叉验证：
- 运行
echo %PATH%，确认输出中确实包含你添加的路径（注意拼写、大小写、反斜杠方向） - 紧接着运行
where composer，确保只返回一行，且路径与你添加的一致 - 再运行
composer --version，成功输出才算闭环 - 如果前两步都对，第三步仍失败，大概率是
composer.bat里调用的php.exe本身有问题（比如扩展缺失、openssl未启用），此时应运行php -m | findstr openssl确认扩展已加载
真正卡住人的地方，往往不是路径加没加，而是加完之后没用where composer验证优先级，也没检查bat文件里那行@php是不是被悄悄改成了别的东西。
