Jenkins本身不感知PHP版本，真正决定PHP版本的是构建节点的环境变量和构建步骤中显式调用的路径；多版本测试依赖手动控制执行上下文，而非插件自动切换。
直接说结论：Jenkins 本身不感知 PHP 版本，真正决定用哪个 php 执行测试的是构建节点上的环境变量和你在构建步骤中显式调用的路径。多版本 PHP 测试不是靠 Jenkins 插件“自动切换”，而是靠你控制命令执行上下文。
为什么 phpunit --version 显示的不是你期望的版本
常见现象：你在 Jenkins 节点上手动运行 php --version 看到的是 8.2，但构建日志里 phpunit 却报错说找不到 mbstring，或者跑出来是 7.4 的结果。
根本原因在于：phpunit 是个 PHAR 文件或 shell wrapper，它依赖当前 shell 环境的 $PATH 和 php 可执行文件位置；而 Jenkins agent 启动时通常不加载用户 shell 配置（如 ~/.bashrc），所以 $PATH 往往是精简版，可能指向系统默认 PHP（比如 Ubuntu 的 /usr/bin/php）。
- 检查 Jenkins 构建日志开头，找类似
Running as SYSTEM或Using node: [node-name]，然后登录对应节点，用sudo -u jenkins bash -c 'echo $PATH && which php'模拟 Jenkins 用户环境 - 不要依赖
which php在 root 下的结果——Jenkins 几乎从不用 root 运行构建 - 如果用了 Docker agent，那 PHP 版本完全由镜像决定，和宿主机无关
在自由风格项目中指定 PHP 8.1 + PHPUnit 10 测试
适用场景：你有固定几台物理/虚拟机节点，已安装多个 PHP 版本（如通过 phpenv、ondrej/ppa 或手动编译），需为某个 PHP 项目绑定特定版本组合。
立即学习“PHP免费学习笔记（深入）”；
实操建议：别碰全局 $PATH，直接在构建步骤里写死路径或封装调用：
- 使用绝对路径最可靠：比如
/opt/php/8.1/bin/php /opt/php/8.1/bin/phpunit --configuration phpunit.xml - 若用
composer install，务必加--no-interaction --prefer-dist，并确认composer.json中"platform"字段声明了目标 PHP 版本（如"php": "8.1.0"），否则 Composer 可能装错扩展依赖 - 在 “构建环境” 中勾选 “设置环境变量”，添加
PHP_BINARY=/opt/php/8.1/bin/php，然后后续所有phpunit命令（只要它尊重该变量）都会走这个解释器 - 避免用
phpenv use 8.1—— 它依赖 shell function，Jenkins 的非交互式 bash 不加载
用 Pipeline 实现 PHP 7.4 / 8.2 / 8.3 并行测试
这是真正 scalable 的做法：每个版本跑在独立容器里，互不污染，也无需在 Jenkins 主机上维护多套 PHP。
关键点不在语法，而在镜像选择与挂载逻辑：
- 优先用官方 PHP Docker 镜像：
php:7.4-cli、php:8.2-cli、php:8.3-cli，它们自带curl、git和基础扩展，够跑phpunit - 用
docker run --rm -v "$WORKSPACE:/workspace" -w /workspace挂载工作区，确保代码和配置可访问 - 别在容器里再装 Composer —— 先在 Jenkins 主机上用对应 PHP 版本的
composer生成vendor/，再挂载进去；否则每次都要重装，慢且易出错 - 示例 stage：
stage('Test on PHP 8.2') {
steps {
sh '''
docker run --rm \
-v "$WORKSPACE:/workspace" \
-w /workspace \
php:8.2-cli \
sh -c "php -v && composer --version && vendor/bin/phpunit --testdox"
'''
}
}
注意 $WORKSPACE 是 Jenkins 内置变量，在单引号 shell 中不会被提前展开，所以必须用双引号包裹整个 sh 块，或改用 script + env 注入。
容易被忽略的扩展与权限陷阱
PHP 多版本测试失败，80% 不是语法问题，而是扩展缺失或路径越权。
-
phpunit报Class 'PHPUnit\Framework\TestCase' not found？先确认vendor/autoload.php是否被正确 require —— 自由风格项目里常漏掉composer install步骤，Pipeline 里则可能因composer install被缓存跳过 - 用
php:8.3-cli镜像跑老项目，发现mysql_connect()报错？那是故意移除的 —— 改用mysqli或PDO，别指望兼容层 - Jenkins agent 运行用户（通常是
jenkins）对/tmp或vendor/无写权限？加chmod -R 755 vendor/或在 Docker 中用-u $(id -u):$(id -g)对齐 UID - 覆盖率报告生成失败？
pcov或xdebug扩展没启用，且两者不能共存；PHP 8.2+ 推荐pcov，但需手动docker-php-ext-enable pcov
最麻烦的从来不是写脚本，而是让不同 PHP 版本在同一个 CI 流程里安静地各干各的活 —— 它们不吵，但会悄悄用错扩展、读错配置、连错数据库。
