php版本统一是项目稳定运行的底线要求，因不同版本存在函数废弃、语法变更、扩展行为差异及安全机制调整；php 7.4 到 8.0 出现函数级兼容性断裂，如 each()、create_function() 和 mb_ereg_replace() 被移除，且 composer 严格校验 php 版本声明。
PHP 版本控制不是“可选动作”，而是项目稳定运行的底线要求——不同 PHP 版本之间存在函数废弃、语法变更、扩展行为差异甚至安全机制调整，不统一版本极易导致本地能跑、线上报错、CI 构建失败、依赖安装中断等实际问题。
PHP 7.4 到 8.0 的函数级兼容性断裂
PHP 8.0 引入了 JIT 和严格类型检查，默认启用 declare(strict_types=1) 影响范围扩大，更关键的是直接移除了多个函数和语法糖。例如：
-
each()函数在 PHP 7.2 被弃用，PHP 8.0 彻底删除；仍有老代码用它遍历数组，升级后直接抛出Fatal error: Uncaught Error: Call to undefined function each() -
create_function()在 PHP 7.2 废弃，PHP 8.0 删除，但部分旧版 CMS 插件或自定义模板引擎仍在用它动态生成回调 -
mb_ereg_replace()等多字节正则函数在 PHP 8.0 中被移除，改用mb_preg_replace()，但后者要求 PCRE2 支持，而某些 Docker 基础镜像默认没开
Composer 安装失败常源于 PHP 版本声明冲突
Composer 会读取 composer.json 中的 "php": "^7.4" 或 "^8.1" 字段，并严格校验当前环境 PHP 版本。常见卡点：
- 本地是 PHP 8.2，但
composer.json写了"php": ">=7.4 → <code>Your requirements could not be resolved to an installable set of packages. - 团队共用同一份
composer.lock，但有人用 PHP 8.0 安装，有人用 PHP 7.4 安装，vendor/下扩展类名或自动加载路径可能不一致，引发Class not found - Laravel 9+ 要求 PHP >=8.0，但若未在
composer.json显式声明，仅靠文档提醒，新人拉代码后直接composer install就会静默降级安装低版本组件，后续运行时报错才暴露
Docker 与本地开发环境版本漂移的实际影响
即使用了 Docker，若 Dockerfile 写的是 FROM php:alpine（默认 latest），下次构建可能拉到 PHP 8.3，而生产环境固定在 8.1 —— 这种“隐式漂移”比手动装错更难排查：
立即学习“PHP免费学习笔记（深入）”；
- PHP 8.2 新增的只读类（
readonly class）在 8.1 下解析失败，报ParseError: Syntax error -
str_contains()等函数在 8.0+ 才有，但某些 CI 镜像仍用 7.4，单元测试里调用就崩 - 扩展加载顺序变化：PHP 8.1 开始
opcache.preload对文件路径更敏感，本地preload.php路径写相对路径，在容器里因工作目录不同而失效
真正麻烦的不是“升不了版”，而是“看不出哪一行代码在哪个版本下会突然失效”。版本控制的价值，是把不确定性压缩到可验证的边界内——比如锁死 php:8.1-cli-alpine3.18，并在 .php-version 和 composer.json 里保持一致，比事后查错误日志快十倍。
