应显式指定 php 解释器路径运行 composer，如 php7.4 /path/to/composer.phar；避免依赖系统默认 php 命令，统一版本可解决 class not found、autoload 失败及 diagnose 报错等问题。
Composer 总调用错 PHP 版本，怎么锁定？
根本原因是 composer 脚本本身是 PHP 写的，它启动时依赖系统默认的 php 命令，而多版本共存下这个命令往往指向非预期版本（比如全局是 PHP 8.1，但项目需要 7.4）。不改环境变量、不重装 Composer，最稳的方式是显式指定 PHP 解释器。
- 运行
composer时，永远用php /path/to/composer.phar形式，而不是直接composer - 把常用路径做成 alias，例如：
alias composer74='php7.4 /usr/local/bin/composer.phar' - 检查当前
composer绑定的 PHP：运行composer --version后立刻执行php -v，两者输出版本必须一致——否则就是调用链出问题
为什么用 update 会突然报 Class not found？
这不是代码问题，是 Composer 在解析 autoload 或加载插件时，用了和 require 阶段不一致的 PHP 版本。尤其当项目 composer.json 中声明了 "php": "^7.4"，但实际执行的是 PHP 8.2，某些扩展（如 ext-intl）行为差异会导致类加载失败。
- 强制统一版本：在项目根目录执行
php7.4 /path/to/composer.phar update，别依赖 PATH 查找 - 避免用
sudo composer update—— root 用户的 PATH 和当前用户不同，PHP 版本极易错位 - CI/CD 脚本里必须写死 PHP 路径，例如 GitHub Actions 中用
run: php7.4 composer.phar install
composer global 的包总在错误 PHP 版本下运行
composer global 安装的命令（如 laravel/installer）本质是 PHP 脚本，它们运行时也依赖当前 shell 的 php 命令。一旦切换 PHP 版本（比如用 brew switch php@8.1），这些全局命令就可能因扩展缺失或语法不兼容而崩溃。
- 不要用
composer global install，改用php8.1 /path/to/composer.phar global require laravel/installer - 全局 bin 目录（如
~/.composer/vendor/bin）里的可执行文件，开头的 shebang（#!/usr/bin/env php）会忽略你手动指定的 PHP，必须改成绝对路径，例如#!/usr/local/bin/php8.1 - 更干净的做法：用
phive管理全局工具，它下载的是独立 PHAR，不依赖系统 PHP 环境
PHP 版本切换后 composer diagnose 还报错怎么办？
composer diagnose 会检查包括 openssl、zlib、phar 在内的扩展是否启用，但这些扩展在不同 PHP 版本中默认开关状态不同。比如 PHP 8.0+ 默认禁用 short_open_tag，而某些旧版 Composer 插件会读取它。
立即学习“PHP免费学习笔记（深入）”；
- 先确认诊断命令本身跑在哪个 PHP 下：运行
which php和php -m | grep -E 'openssl|zlib|phar' - 如果
diagnose提示 “The openssl extension is missing”，不是没装，而是当前 PHP 没启用 —— 检查对应版本的php.ini（如/usr/local/etc/php/7.4/php.ini）里是否有extension=openssl - Mac 上用 Homebrew 安装多个 PHP 时，每个版本的
php.ini是独立的，改错文件毫无作用
最麻烦的其实是 composer 自身的缓存机制 —— 它会缓存不同 PHP 版本下的 autoloader 结构，换版本后不清理就容易加载错类。遇到诡异的 autoload 错误，先删 vendor/autoload.php 和 vendor/composer/autoload_*.php，再重装。
