根本原因是composer依赖系统path中首个php可执行文件，而非自身配置问题；需通过which php/where php确认路径，用完整路径临时调用，或永久将php目录加入path修复。
Composer 找不到 PHP 或报错 PHP is not recognized
根本原因不是 Composer 本身的问题，而是它运行时依赖系统 PATH 中第一个可用的 php 可执行文件。windows 下常见于没把 PHP 目录加进环境变量，macos/linux 则常因 shell 初始化文件（如 ~/.zshrc）里没正确导出 PATH。
实操建议：
- 先在终端运行
which php（macOS/Linux）或where php（Windows），确认当前生效的 PHP 路径 - 如果返回空，说明系统根本找不到
php—— 此时 Composer 必然失败，别急着动 Composer 配置 - 临时指定 PHP 路径启动 Composer：直接用完整路径调用，例如
/usr/local/bin/php /usr/local/bin/composer install - 永久修复：把 PHP 的 bin 目录（如
/opt/homebrew/bin、C:php）加进系统 PATH，然后重启终端
用 composer config --global platform.php 是无效的
这个配置项只影响依赖解析阶段的“模拟 PHP 版本”，比如告诉 Composer：“假装我用的是 PHP 8.1”，从而允许安装只兼容 8.1+ 的包。它完全不改变 Composer 运行时实际调用哪个 php 二进制文件。
常见错误现象：
立即学习“PHP免费学习笔记（深入）”；
- 设了
platform.php=8.2，但composer -V仍报ParseError—— 因为底层 PHP 解释器其实是 7.4，语法不支持 - 本地 PHP 是 8.3，但 CI 环境是 8.1，仅靠
platform.php无法让本地复现 CI 的依赖解析结果 - 这个值不会写入
composer.json，只存于全局配置~/.composer/config.json，对项目协作无实质帮助
在多 PHP 版本环境下切换 Composer 使用的 PHP
没有官方“绑定”机制，只能靠外部控制。本质是让 composer 命令背后调用的 php 可执行文件可变。
实操建议：
- macOS/Linux 推荐用
alias区分：在~/.zshrc里加alias composer81='/opt/homebrew/bin/php81 /usr/local/bin/composer'，然后用composer81 install - Windows 可以建多个批处理脚本，如
composer-8.2.bat，内容为"C:php8.2php.exe" "C:composercomposer.phar" %* - 避免用
php -d传参覆盖 ini 设置来“伪装”版本 —— Composer 启动后会重新加载自己的php.ini，这类覆盖大概率失效 - 某些 ide（如 phpstorm）允许为每个项目单独指定 PHP 解释器路径，此时它的内置 Composer 工具会自动使用该 PHP，这是最省心的场景
Windows 上用 XAMPP/MAMP/WAMP 时 Composer 总调用错 PHP
这些集成环境默认把自身 PHP 加进系统 PATH，但顺序可能靠后；而 Composer 安装器（.exe）又自带一个精简版 PHP，优先级更高 —— 结果就是你改了 XAMPP 的 PHP，Composer 却还在用它自带的旧版本。
关键判断点：
- 运行
composer --version后立刻看输出第一行，它会打印类似PHP version: 8.0.28 (c:xamppphpphp.exe)的信息 —— 这才是真实路径 - 如果显示的是
php.exe但没给绝对路径，说明它来自 PATH 搜索，此时用where php确认顺序 - 最稳妥做法：卸载 Composer Windows Installer 版，改用
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"手动安装，这样它彻底交由系统 PHP 管理 - 不要试图修改
composer.phar头部 shebang（Windows 不认），也没用
Composer 的 PHP 路径问题，从来不是配置能绕过去的——它卡在进程启动那一瞬间，谁先被 PATH 找到，谁就说了算。很多人花半天调 config，其实该先查 which php 和 composer --version 的第一行输出。