确认 composer 实际使用的 PHP：运行 composer --version（首行显示真实 PHP 路径与版本），或 head -n1 $(which composer) 查 shebang 行；两者必须一致，否则操作可能错位。
怎么确认当前 composer 实际用的是哪个 PHP？
别只信 php -v，它只反映默认 PHP；composer --version 第一行会明确写出真实调用的 PHP 路径和版本（例如 PHP 8.2.15 (cli)）。更底层的验证是：head -n1 $(which composer)，看 shebang 行——如果是 #!/usr/bin/env php，说明它走 $PATH 里第一个 php；如果是 #!/usr/bin/php8.1，那就是硬编码路径。这两者必须一致，否则所有后续操作都可能错位。
写一个可靠切换脚本的关键点
脚本核心不是“改环境”，而是“喂对解释器”。它必须绕过 alias、PATH、软链等易失效机制，直接调用目标 PHP + composer.phar。
- Linux/macOS：脚本第一行必须是
#!/bin/sh，然后显式写死或动态获取 PHP 路径，例如/usr/bin/php8.1 /opt/composer/composer.phar "$@" - macOS Homebrew 用户注意：
php@8.1的实际路径是/opt/homebrew/bin/php@8.1，@符号不能漏 - Windows 批处理（
composer81.bat）内容应为：@php81 "%~dp0composer.phar" %*，且确保php81是已配置的命令或在 PATH 中 - 脚本中不要用
COMPOSER_PHP环境变量——如果which composer返回的是 shell 脚本（shebang 是#!/usr/bin/env php），这个变量就无效
运行环境调整时最容易踩的坑
很多人以为切完 PHP 就万事大吉，结果 vendor/autoload_static.php 一加载就报 ParseError 或 Class not found。这是因为：
-
vendor目录和composer.lock必须重装——不是“建议”，是硬性要求。不同 PHP 版本生成的 autoload 文件语法/结构不兼容（比如 PHP 8.2 的match表达式在 7.4 下根本无法解析） -
config.platform.php只骗依赖求解器，不改运行时。它不影响scripts里写的"test": "php tests/run.php"，也不影响扩展是否真正加载 - 宝塔用户尤其要注意：每个 PHP CLI 版本（如
/www/server/php/81/bin/php）读取的是各自隔离的全局配置，composer config -g必须用对应 PHP 路径执行，否则镜像、repo 配置全白设
为什么不能靠 alias 或软链长期管理？
alias composer='php8.1 /path/to/composer.phar' 在非交互式 shell（如 Git hooks、CI pipeline、Makefile）里大概率失效。而软链（ln -sf composer81 /usr/local/bin/composer）看似方便，但一旦多个项目同时开发，极易互相覆盖、误操作。最稳的方式是：每个项目根目录放一个 bin/composer 脚本，内容固定为 /www/server/php/81/bin/php /usr/bin/composer.phar "$@"，并确保 chmod +x。这样，./bin/composer install 的行为完全可预期，不依赖任何外部环境状态。
