Composer不配置PHP路径，完全依赖系统php命令；需用which php或where php确认实际路径，php -v和php -m检查版本及openssl等扩展是否启用，php --ini验证加载的php.ini是否正确。
Composer 本身不配置 PHP 环境路径，它依赖系统已有的 php 命令——也就是说，composer 能否运行、运行得是否正确，完全取决于你终端里敲 php 时调用的是哪个二进制文件、它是否启用必要扩展、是否在 PATH 中。
确认当前 php 命令指向哪个可执行文件
很多人卡在“composer install 报错”，但根本问题出在 php 自身。先搞清你实际在用哪个 PHP：
- 运行
which php（Linux/macOS）或where php（Windows），看输出路径是否是你期望的版本（比如/www/server/php/80/bin/php或C:\php\php.exe） - 如果返回空或指向
/usr/bin/php这类系统默认路径，而你实际用的是宝塔、phpstudy 或自编译 PHP，那大概率就是错的 - 运行
php -v和php -m | grep -E "openssl|zlib|json|mbstring|curl"，缺任意一项都会导致 composer 后续失败（如file_get_contents(): php_network_getaddresses: getaddrinfo failed）
让 composer 明确使用指定 PHP 版本
Composer 的 PHAR 文件第一行是 #!/usr/bin/env php，它会去环境变量 $PATH 里找第一个 php。你不能靠改 composer 文件头来硬绑，而是要控制环境本身：
- 最稳妥：创建软链接统一入口 ——
sudo ln -sf /www/server/php/80/bin/php /usr/local/bin/php（宝塔用户）或mklink /D C:\php C:\php-8.1.22（Windows 多版本管理） - 临时覆盖：在执行前指定 PHP 路径，例如
php /path/to/composer.phar install，绕过env php查找逻辑 - 避免 alias：别在 shell 配置里写
alias composer='php /xxx/composer.phar'，某些 CI 或子进程不会继承 alias，且和composer create-project内部调用冲突
PATH 和 php.ini 路径不一致导致的隐性故障
常见现象：php -v 显示 PHP 8.1，php --ini 却加载了 PHP 7.4 的 php.ini；或者 CLI 和 Web 使用不同配置，造成 extension 启用状态不一致。
立即学习“PHP免费学习笔记（深入）”；
- 运行
php --ini，确认 Loaded Configuration File 指向你修改过的那个php.ini，而不是Scan for additional .ini files下某个干扰项 - Windows 用户注意：phpstudy、WAMP 等集成环境通常把 CLI 的
php.ini放在php/ext/同级目录，而非 Apache 模块用的那个；别直接复制 Apache 的 ini 文件过去 - Linux 宝塔用户：PHP 管理 → 当前版本 → 配置文件，那个路径才是 CLI 实际读取的，改完要重启 PHP 服务（不是 Apache/Nginx）
真正麻烦的从来不是“怎么配”，而是配完之后没人验证 php 命令背后到底是谁、加载了什么配置、启用了哪些扩展。很多 composer 报错信息模糊（比如 “The requested package does not exist”），其实只是 openssl 扩展没开，连 HTTPS 源都连不上。
