php 7.4 到 8.3 的核心断层在 7.4→8.0：引入 ??=、match、联合类型，移除 mysql_* 等函数，错误处理更严格；后续版本为渐进增强，但类型系统、只读属性、dnf 类型等均需对应版本支持。
PHP 版本差异直接影响代码能否运行、安全是否有保障、以及新语法能不能用——不是“升级了更好”，而是“不升级可能跑不动、修不了、甚至被攻破”。
PHP 7.4 到 8.3 的关键断层在哪
真正影响日常开发的不是小版本（如 8.1.12 → 8.1.25），而是大版本跨越：7.4 → 8.0 是最大分水岭，8.0 → 8.1 → 8.2 → 8.3 是渐进增强。核心断层包括：
-
??=（空合并赋值）、match表达式、联合类型（string|int）在 8.0+ 才支持，7.4 写了直接 Parse error - 8.0 移除了
mysql_*、mcrypt_*等废弃函数，调用即Fatal error: Uncaught Error: Call to undefined function - 8.1 引入
readonly类属性，8.2 加入disjunctive normal form types（如(A|B)&(C|D)），这些在低版本完全不可用 - 错误处理收紧：8.0+ 将更多警告（Warning）升级为
TypeError或ValueError，比如传错类型给strlen()在 7.4 是 warning，在 8.0+ 是 uncaughtTypeError
哪些函数/行为在不同版本里表现不一致
看似一样的函数，参数容错性或返回值可能悄悄变了：
-
json_encode()：8.0+ 默认启用JSON_INVALID_UTF8_IGNORE，旧版需手动加 flag 才能忽略非法 UTF-8；否则同样输入会一个返回false，一个返回空字符串 -
array_key_exists()：8.0+ 对对象属性不再触发__isset()，而 7.4 会——如果依赖魔术方法做权限判断，升级后逻辑可能失效 -
gettype()：8.0+ 对resource返回"resource"（之前是"resource (closed)"或类似），用字符串匹配判断资源状态的代码会出错 -
date_parse_from_format()：8.1+ 对模糊格式（如"Y-m"输入"2023-02-15"）返回更严格的error_count，旧版可能静默接受
升级 PHP 版本前必须检查的三件事
别只看 php -v，很多坑藏在扩展和配置里：
立即学习“PHP免费学习笔记（深入）”；
- 确认所有用到的扩展已编译适配目标版本（尤其是
igbinary、msgpack、redis等 C 扩展），php -m不报错 ≠ 功能正常，要实际调用测试 - 检查
php.ini中是否用了已被移除的指令，例如always_populate_raw_post_data（7.0 移除）、mbstring.func_overload（7.2 移除）、zend.ze1_compatibility_mode（早已废弃） - 验证 Composer 依赖：运行
composer update --dry-run，看是否有包声明"php": "^7.2"却没兼容 8.x，或者用了class_alias()动态注册类名但未处理命名空间变更
为什么有些老项目不敢升到 PHP 8+
不是开发者懒，是现实约束硬生生卡住：
- 托管环境限制：共享主机或老旧云平台只提供 PHP 7.3/7.4，且不开放升级权限
- 第三方 SDK 绑定死版本：比如某支付网关的 PHP SDK 只维护到 7.2，其
curl_setopt_array()调用方式与 8.0+ 的 strict mode 冲突 - 框架生命周期：Laravel 6.x 最高支持 PHP 7.4，强行升到 8.0 会导致
vendor/autoload.php加载失败（因ComposerClassLoader内部用了不兼容的返回类型声明） - 静态分析工具滞后：旧版
phpstan或psalm对 8.1+ 的枚举（enum）和只读类（readonly）无识别能力，CI 流程直接挂掉
版本差异最麻烦的从来不是“新功能多炫酷”，而是那些不报错、不崩溃、但结果悄悄变的隐性行为——比如时区处理、浮点数比较、异常继承链顺序，这些细节一旦漏测，上线后就是深夜告警。
