PHP版本过低会导致Composer安装失败、扩展不可用、安全漏洞无法修复及主流框架拒绝运行；迁移需同步处理语法兼容性、废弃函数、扩展依赖和第三方库约束；关键要检查composer.json中"php"字段限定的版本上限。
PHP 版本过低（比如还在用 5.6 或 7.0）会导致 Composer 安装失败、扩展不可用、安全漏洞无法修复，甚至 Laravel、Symfony 等主流框架新版直接拒绝运行。迁移不是“升级 PHP 就完事”，而是要同步处理语法兼容性、废弃函数、扩展依赖和第三方库约束。
检查当前项目真实依赖的 PHP 版本上限
很多人只看 php -v，但关键其实是项目自身锁死的版本。先确认：
-
composer.json中"php"字段（如"^7.2"或">=7.4.0 ），这是 Composer 安装时的硬性门槛 - 运行
composer check-platform-reqs，它会比对当前 PHP 版本与所有 require 的扩展（如ext-mbstring、ext-pdo_mysql）是否满足 - 检查有没有手动调用已被移除的函数，比如
mysql_connect()（PHP 7.0 移除）、mcrypt_encrypt()（7.2 废弃，7.3 移除）
逐级升级 PHP 版本，别跳步
从 PHP 5.6 直升 8.2 是高风险操作。中间缺失的废弃提示、错误级别变化、严格类型校验都会被跳过，导致上线后才暴雷。推荐路径：
- 5.6 → 7.2（最小兼容 Laravel 5.5、Symfony 4）
- 7.2 → 7.4（支持短闭包、类型声明强化，是 LTS 版本）
- 7.4 → 8.0（引入联合类型、属性类型、
str_starts_with()等新函数） - 8.0 → 8.1/8.2（仅需关注枚举、只读类、
never类型等增量变更）
每次升级后，务必开启 error_reporting = E_ALL 并查看日志，PHP 7.4+ 默认不报 E_DEPRECATED，需显式加上。
立即学习“PHP免费学习笔记（深入）”；
替换已移除扩展和函数调用
常见踩坑点集中在字符串、加密、时区和数组函数上：
-
mysql_*全系列函数 → 改用PDO或mysqli，注意mysql_real_escape_string()没有直接等价物，必须改用预处理 -
mcrypt_*→ 改用openssl_encrypt()/openssl_decrypt()，注意 IV 长度、填充方式、密码派生逻辑完全不同 -
each()（PHP 7.2 移除）→ 改用foreach ($arr as $k => $v) -
create_function()（7.2 移除）→ 改用匿名函数或eval()（不推荐） - 时区未设置导致
date()返回警告 → 在入口加date_default_timezone_set('Asia/Shanghai')
Composer 和 vendor 依赖必须重装
PHP 版本变更后，不能复用旧的 vendor/。必须：
- 删掉
vendor/和composer.lock - 确保
composer.json的"php"字段已更新为目标版本（如"^8.1"） - 运行
composer install（不是update），让 Composer 按新平台约束重新解析依赖树 - 特别注意：有些包在 PHP 8+ 下要求最低版本提升（如
monolog/monolog ^2.0才支持 8.0），旧版可能直接安装失败
迁移中最容易被忽略的是扩展 ABI 变更——比如 PHP 8.0 后 ext-redis 的构造函数签名变了，new Redis() 可能抛出 RedisException 而非连接失败，得查具体扩展的 CHANGELOG。
