PHP 7.2升级到8.0会踩哪些坑-php教程-PHP中文网

不改代码，90%的老项目在php 8.0下无法启动或关键路径崩溃；主要因函数签名强制类型校验、mysql_*等函数彻底移除、错误升级为typeerror、扩展失效及静默逻辑变更。

php 7.2升级到8.0会踩哪些坑

PHP 7.2 升级到 8.0 不是“改个版本号就能跑”，而是会触发大量运行时错误、语法拒绝、扩展失效和逻辑静默变更。最直接的结论是：不改代码，90% 的老项目在 PHP 8.0 下无法启动或关键路径崩溃。

PHP 8.0 强化了类型系统，很多内置函数的参数类型从“宽松”变成“强制”。一旦调用时传入不符合新签名的值，直接抛 Fatal error: Uncaught TypeError。

array_key_exists() 第二个参数现在必须是 array|ArrayObject，传 null 或字符串会崩；老代码里常见 array_key_exists('id', $_GET)，但若 $_GET 被意外 unset，就挂
json_decode() 的第二个参数（$assoc）现在必须是 bool，传 1 或 'true' 会报错；很多老项目写成 json_decode($str, 1)，得全改成 true
preg_replace() 的 $limit 参数现在不允许负数，传 -1 直接 fatal；有些正则批量替换逻辑依赖这个行为，得重写

PHP 8.0 彻底移除了 mysql_* 系列函数（早在 7.0 就 deprecated），也清掉了 mcrypt_* 和 ftp_* 扩展。但更隐蔽的坑是那些“看似还在、实则行为已变”的组件：

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

get_class() 在对象为 null 时不再返回 false，而是抛 TypeError；很多框架的反射/ORM 初始化逻辑里有类似 if (!get_class($obj)) { ... } 的守卫，现在会中断
create_function() 已被完全移除，所有用它动态生成回调的地方（比如老版 ThinkPHP 的钩子、某些模板引擎的 lambda 表达式）必须重构成 fn() 或匿名函数
ext/soap 的 WSDL 缓存机制在 8.0 中默认关闭，且 cache_wsdl 选项被标记为 deprecated；如果项目依赖本地 WSDL 文件缓存提速，升级后首次请求会明显变慢甚至超时

PHP 8.0 默认启用 zend.assertions = 1 且 assert.exception = 1，同时弱类型比较（==）在涉及数字字符串时行为更严格。这些不会立刻报错，但会让原有逻辑“悄悄走偏”：

'123abc' == 123 在 7.2 返回 true，在 8.0 仍为 true，但 '123a' == 123 变成 false（因为解析提前终止）；若业务里有用字符串 ID 做松散比对的权限校验，可能漏放行或误拦截
函数返回类型声明（如 function getId(): int）一旦实际返回 null 或 string，不再是 warning，而是 TypeError；尤其 ORM 模型中未设默认值的字段，getXXX() 方法容易在这里翻车
mbstring 扩展的默认编码从 ISO-8859-1 改为 UTF-8，mb_strlen('中文') 结果不变，但 mb_substr('中文', 0, 1) 在旧环境可能截出乱码字节，升级后反而“看起来正常了”，掩盖了原始数据编码混乱的问题

PHP 8.0 把大量 E_WARNING 和 E_NOTICE 提升为 TypeError 或 ValueError，并统一用 throw 抛出异常。这意味着以前靠 @ 抑制、靠 set_error_handler() 忽略的错误，现在会穿透到顶层，中断流程：

file_get_contents('http://...') 在 DNS 失败时，7.2 返回 false 并触发 warning；8.0 直接抛 ValueError，若没 try/catch，整个请求崩掉
json_encode() 遇到不可序列化对象（如 Closure、resource）时，7.2 返回 false；8.0 抛 ValueError，很多 API 层的兜底 json_encode($data) ?: '[]' 写法直接失效
自定义错误处理器若没适配 TypeError 类异常（比如只捕获 Exception），会导致未处理异常直接暴露给用户，甚至记录为空白日志