Composer报“找不到PHP可执行文件”是因为它只认PHP_BINARY或PATH中首个可用php，不自动猜测路径；php -v正常但composer diagnose通过，是因diagnose仅检查当前PHP进程而非Composer启动所用PHP，导致误判。
Composer报“找不到PHP可执行文件”，不是它坏了，而是启动时根本没找到php命令——它不猜路径，只认PHP_BINARY或PATH里第一个能跑的php。
为什么php -v正常但composer diagnose报错？
composer diagnose只检查当前 PHP 进程（也就是你终端里正在跑的那个 PHP）是否满足扩展、权限等条件，它完全不验证 Composer 自己是用哪个php启动的。哪怕PHP_BINARY指向一个不存在的路径，只要当前 shell 下php能运行，diagnose就显示 OK，然后composer install直接崩。
- 典型误判场景：CI 脚本里写了
export PHP_BINARY=/opt/php/bin/php，但镜像里实际路径是/usr/bin/php - Dockerfile 中
ENV PHP_BINARY=/usr/local/bin/php，构建后 php 被重装到新位置 - Windows 上设了系统环境变量
PHP_BINARY，但没重启终端，Composer 启动时读的是旧值
Windows 下composer.bat为何无视PHP_BINARY？
官方安装包附带的composer.bat是批处理脚本，内部写死调用php命令，完全不读取PHP_BINARY。哪怕你在系统变量里设了PHP_BINARY=C:\xampp\php\php.exe，它也视而不见。
- 验证方法：用记事本打开
composer.bat，搜php "，大概率看到这行：php "%~dp0composer.phar" %* - 最稳解法：删掉
composer.bat，改用php composer.phar全局 alias（PowerShell 中可加function composer { php C:\tools\composer.phar @args }） - 次选方案：手动编辑
composer.bat，把php替换成绝对路径，例如"C:\xampp\php\php.exe"（注意英文双引号，路径含空格时必加）
Linux/macOS 下硬编码PHP_BINARY的实操要点
在 shell 配置文件（如~/.zshrc）里写死路径，比依赖PATH更可控，尤其当你有多个 PHP 版本共存时。
立即学习“PHP免费学习笔记（深入）”；
- 临时生效（当前终端）：
export PHP_BINARY=/opt/homebrew/bin/php - 永久生效（推荐）：
echo 'export PHP_BINARY=/opt/homebrew/bin/php' >> ~/.zshrc && source ~/.zshrc -
PHP_BINARY控制 Composer 自身运行逻辑（install、update等），而COMPOSER_BINARY只影响vendor/bin/下生成的代理脚本（如phpunit），别混用 - 如果用了
sudo composer install，记得sudo -E保留环境变量，否则PHP_BINARY会丢失
硬编码路径后仍报错？三个关键检查点
设了PHP_BINARY不等于万事大吉，还要确认这个php是否真能干活：
- 运行
/path/to/php -v，必须输出版本号；若报VCRUNTIME140.dll缺失，是 VC 运行库问题，和 Composer 无关 - 确认该
php是 CLI 版本，不是 Apache SAPI：可用php -S localhost:8000测试是否支持内置服务器 - 检查扩展是否加载：
php -m | grep -E 'openssl|curl'，缺哪个就补哪个（M1/M2 上 Homebrew 安装的 PHP 常缺这些）
最容易被忽略的是：Windows 注册表项HKEY_LOCAL_MACHINE\SOFTWARE\PHP里的PhpPath和IniFilePath，即使你把php.exe放进PATH，Composer 仍可能优先读注册表——这点连很多老手都踩过坑。
