PHP版本控制最常踩的三个坑是：一、误用php:latest镜像导致部署失控，应固定小版本标签并校验php -v；二、忽略扩展ABI兼容性，需重编译或用docker-php-ext-install安装；三、本地与线上PHP版本不一致且未验证兼容性，须统一版本并多版本测试。
PHP版本控制最常踩的三个坑
不是“要不要做版本控制”，而是“怎么做才不翻车”。现实中，90%的PHP项目出问题，都卡在版本控制的执行细节上——比如线上突然报错说 str_contains() 不存在，结果发现是服务器悄悄升到了PHP 8.0，而代码只在7.4下测试过。
误用 php:latest 镜像导致部署不可控
这是Docker环境下最隐蔽也最危险的习惯。看似省事，实则等于把版本决策权交给了镜像维护者——某天 php:latest 指向了PHP 8.3，你的CI就可能直接挂掉，连错误日志都来不及看。
- 永远用带小版本号的标签：
php:8.2-fpm-alpine，而不是php:8-fpm或php:latest - 在
composer.json中显式声明PHP平台要求："platform": {"php": "8.2.15"}，防止composer install拉取不兼容的包 - CI流程中加一行校验：
php -v | grep -q "8\.2\." || exit 1，确保环境真实匹配
忽略扩展 ABI 兼容性，一升级就报 Unable to load dynamic library
PHP扩展不是“装上就能用”。从7.4升级到8.0后，redis.so、mongodb.so 这类二进制扩展必须重新编译，否则启动时就会出现这个警告，且扩展完全失效。
- 不要手动复制旧系统里的
.so文件——ABI（应用二进制接口）已变 - 用官方推荐方式安装扩展：
docker-php-ext-install mysqli或pecl install redis，它会自动适配当前PHP版本 - 检查扩展是否真正启用：
php -m | grep redis，而不仅是看extension=redis.so是否在php.ini里
本地开发和线上环境用不同PHP版本，却没做兼容性验证
开发者用Mac自带的PHP 8.1，生产用Ubuntu的PHP 8.2，看起来只差一个小版本，但 match 表达式行为、json_encode() 的默认选项、甚至 foreach 对引用数组的处理都可能有细微差异。
立即学习“PHP免费学习笔记（深入）”；
- 开发机上用
phpbrew或asdf精确匹配线上PHP版本，别依赖系统自带 - 在CI中跑多版本测试：
phpunit --configuration phpunit-8.1.xml和phpunit --configuration phpunit-8.2.xml - 静态分析工具要覆盖目标版本：
phpstan analyse --level=8 --php-version=8.2，否则漏掉新版本废弃函数
版本控制真正的难点不在“选哪个版本”，而在于让整个工具链（Docker、Composer、CI、静态分析、运行时扩展）全部对齐同一套语义化版本约束——少一个环节松动，就可能在凌晨三点弹出一个 Fatal error: Uncaught Error: Call to undefined function。
