Composer 不管理 PHP 版本，多版本测试依赖 CI/CD 的 matrix 策略并行执行 composer install；需用 setup-php 动态切换版本、显式声明扩展、禁用跨版本 vendor 缓存，并通过 check-platform-reqs 真实校验环境兼容性。
首先得明确一个核心概念：Composer 本身并不负责管理 PHP 版本。我们常说的“多 PHP 版本测试矩阵”，本质上是在 CI/CD 流水线（比如 GitHub Actions 或 GitLab CI）中玩的一个组合策略——让不同版本的 PHP 并行运行 composer install 和后续的测试命令。所以，如果你试图在 composer.json 里写死多个 PHP 版本，那不仅没有意义，也完全起不到真正的测试作用。
GitHub Actions 中触发多 PHP 版本安装与依赖解析
这里的关键，在于利用 CI 工具的 matrix 策略，让任务在不同 PHP 版本上并行执行，并且每一轮都独立、完整地跑一遍 composer install。在 GitHub Actions 里，官方提供的 actions/setup-php 是最稳定可靠的选择，它能自动切换系统级的 PHP 环境，并配置好相应的 php.ini 和扩展路径。
一个常见的错误是手动使用类似 sudo update-alternatives --config php 的命令来切换版本。这种做法不仅不可靠，还很容易污染环境，或者被各种缓存机制干扰，导致结果难以预料。
- 矩阵策略是必须的：务必将
php-version放入strategy.matrix中，而不能只写死一个固定版本。 - 扩展要显式声明：通过
extensions参数明确列出所需扩展（例如mbstring, curl, json），否则某些扩展可能缺失，直接导致composer install失败。 - 环境配置要稳定：建议加上
coverage: none或调整ini-values（如设置memory_limit: -1），以避免因不同 PHP 版本的默认配置差异而引发的随机性失败。 - 配置示例片段：
strategy: matrix: php-version: ['8.1', '8.2', '8.3'] include: - php-version: '8.1' extensions: ['mbstring', 'curl', 'json', 'xml'] - php-version: '8.2' extensions: ['mbstring', 'curl', 'json', 'xml', 'opcache']
如何让 Composer 拒绝安装不兼容的包
这里有个误区需要澄清：依赖 composer.json 里的 config.platform.php 设置，其实只能“伪装”PHP 版本，骗过依赖检查。它并不会真正阻止安装行为——其作用仅仅是告诉 Composer：“请把当前环境当作是这个版本的 PHP 来处理”。要想真正拦截不兼容的包，得靠 platform-check 功能配合严格的 require 约束。
立即学习“PHP免费学习笔记（深入）”；
"config": { "platform": { "php": "8.2.0" } }仅影响composer install时的平台包解析逻辑，不影响实际的运行时行为。- 更有效的方法是在
require部分直接锁定扩展版本，例如"ext-mbstring": "^1.0"，并配合composer validate --strict来检查平台一致性。 - 在 CI 流程中，应该增加一步：
composer check-platform-reqs --no-dev。这个命令会真实检测当前的 PHP 环境是否满足require中声明的所有扩展和版本约束。
为什么 vendor 缓存不能跨 PHP 版本共享
这是很多问题的根源。不同 PHP 版本编译的扩展（尤其是像 igbinary、redis 这样的 C 扩展）其应用二进制接口（ABI）是不兼容的。更重要的是，composer install 生成的 vendor/autoload.php 及相关文件里，会嵌入 PHP 版本标识和特定的扩展加载逻辑。如果混用缓存，轻则导致 Fatal error: Cannot declare class ... because the name is already in use 这类错误，重则出现扩展函数未定义的致命问题。
- 缓存必须区分版本：GitHub Actions 默认会缓存
vendor目录，必须禁用此行为，或者按照php-version进行分维度缓存。例如，缓存键可以这样设计：key: ${{ runner.os }}-composer-${{ hashFiles('**/composer.lock') }}-${{ matrix.php-version }}。 - 环境隔离是前提：本地开发或许无需模拟多版本，但在 CI 环境中，必须确保每次
composer install都是在干净、隔离的环境下执行的。 - 忽略 vendor 不等于安全：别以为在
.gitignore里忽略了vendor/目录就万事大吉了——如果缓存策略配置错误，问题照样会出现。
话说回来，真正的难点不在于写几行 matrix 配置，而在于深入理解 Composer 的平台感知机制，以及 CI 环境中 PHP 运行时的实际约束边界。很多“本地安装顺利，CI 却报错”的诡异问题，其根源往往都出在 platform 配置与缓存策略的错配上。
