PHP 8 移除了 mysql_* 函数、create_function()、each()、__autoload() 等，强化参数类型校验（如 string 不接受 null）、升级错误级别（Warning→Error），并严格化 array_key_exists() 等函数的输入类型。
PHP 7 升级到 PHP 8 后直接报错，大概率不是语法错误，而是某些写法在 PHP 8 中被移除或严格化——尤其是那些 PHP 7.4 就已标记为 Deprecated、PHP 8.0 彻底删除的特性。
PHP 8 移除了哪些函数和用法
最常踩坑的是已被彻底删除的函数和扩展接口：
-
mysql_*系列函数（早在 PHP 7.0 就移除，但部分老项目仍残留调用） -
create_function()：PHP 7.2 弃用，PHP 8.0 彻底删除，必须改用匿名函数 -
each()：PHP 7.2 弃用，PHP 8.0 删除，循环应改用foreach -
mysqli_bind_param()的旧式引用传参（如mysqli_bind_param($stmt, 's', $var)在 PHP 8 中要求变量必须已声明且非 null） -
__autoload()：PHP 7.2 弃用，PHP 8.0 删除，必须使用spl_autoload_register()
检查报错时若看到 Fatal error: Uncaught Error: Call to undefined function，优先 grep 这些函数名。
参数类型与 nullability 严格化
PHP 8 强制执行参数类型声明的运行时校验，尤其对 null 值更敏感：
立即学习“PHP免费学习笔记（深入）”；
- 函数声明了
string $name，但传入null，PHP 7 可能静默转为空字符串，PHP 8 直接抛TypeError - 可空类型必须显式声明为
?string，否则null不被接受 - 类属性类型声明（如
public string $id;）在 PHP 8 中要求构造时或初始化时赋值，未赋值会触发Error
典型报错：TypeError: Cannot assign null to property App\User::$email of type string。解决方式不是加 @ 抑制，而是补默认值或改用 ?string。
短数组语法与动态属性访问的兼容性陷阱
看似安全的写法，在 PHP 8 下可能因解析规则变化而失效：
-
$arr[0]['key'] ?? null在 PHP 7 允许对未定义索引做空合并，PHP 8 对左侧表达式求值更严格，若$arr[0]本身为null或不存在，会先报Notice: Trying to access array offset on value of type null，再触发??；建议改用($arr[0]['key'] ?? null)加括号，或用isset($arr[0]['key']) ? $arr[0]['key'] : null - 动态属性（
$obj->$key）在 PHP 8.2+ 已废弃，但 PHP 8.0/8.1 中若$key为null或数字字符串（如"0"），行为与 PHP 7 不同，可能返回空或报错 -
array_key_exists(null, $arr)在 PHP 7 返回false，PHP 8 报TypeError，需确保 key 是 string/int
错误报告级别升级导致“突然报错”
PHP 8 默认将大量 E_DEPRECATED 和 E_NOTICE 提升为 TypeError 或 Error，例如：
- 调用未定义方法：
PHP 7 → Warning，PHP 8 → Error - 数组解构中元素不足：
[$a, $b] = [1];在 PHP 7 静默设$b = null，PHP 8 抛ValueError - 使用
list()解构非数组值（如null或对象）：PHP 7 可能忽略，PHP 8 直接TypeError
临时调试可用 error_reporting(E_ALL & ~E_ERROR) 缩小范围，但不能替代修复——PHP 8 的 Error 是不可捕获的致命错误（除非用 set_error_handler 拦截并转异常）。
真正麻烦的不是语法改写，而是那些藏在条件分支里、只在特定数据下触发的隐式类型转换或未定义行为；上线前务必用生产级数据集跑一遍全链路，别只靠单元测试覆盖 happy path。
