PHP 8.5.7 类型收窄后，这些弱类型坑没了【排雷手册】

先说一个基础判断：PHP 8.5.7 确实不存在，截至2026年6月，官方从未发布过这个版本。所谓"8.5.7"，大概率是误读（比如把8.4.7看成了8.5.7），也可能来自非官方打包或开发分支的误标。如果你在哪看到了这个版本号，建议先用 php -v 确认真实版本，然后按官方渠道安装 PHP 8.3 或 8.4 稳定版。

不过，绕开版本争议不谈，这篇文章真正想聊的是：当 PHP 的类型检查变得越来越严格时，那些曾经被我们"习惯性容忍"的弱类型问题，到底会怎样爆发。

有一点需要明确——类型收窄并不会"自动修复"弱类型坑。它的真实作用是：让那些原本被静默忽略的类型错误，直接暴露在光天化日之下。说白了，坑还在那里，只是不再埋得那么深了。

为什么 strlen(null) 会直接报错

这其实不是 Bug，而是类型收窄机制生效后的必然结果。在 PHP 8.x 的演进过程中，函数参数的类型校验越来越严格。strlen() 的签名明确要求参数是 string 类型，你传一个 null 进去，它会毫不客气地抛出一个 Fatal error: Uncaught TypeError。

以下场景极其容易踩雷：

• 从 json_decode($json, true)['name'] ?? null 取到值后，直接丢进 strlen()，而 ['name'] 如果实际不存在，数组访问返回 null——你以为是空字符串，实际上是个 null
• 数据库字段值为 NULL，PDO 返回 null，未做判空就传入 strlen()
• 表单某字段未提交，$_POST['field'] 可能是 '' 或未定义，用了 ?? null 后仍有可能得到 null

安全写法其实很简单：strlen((string) ($value ?? ''))，或在调用前先用 is_string($value) 做个判定。习惯养成之后，这类问题基本不会找上门。

match 表达式：不再帮你"兜底"

在 PHP 8.x 中，match 表达式默认开启了 exhaustiveness 检查（尤其在配合静态分析时）。它不会像旧版那样"你写多少我算多少"，而是要求你显式覆盖所有可能的类型分支。

举个例子，这段代码在新版下会直接警告甚至报错：

$result = match (gettype($input)) {
    'string' => strtoupper($input),
    'integer' => (string) $input,
};

原因是 gettype(null) 返回的是 'NULL'，分支里没写；gettype([]) 返回 'array'，也没写。你觉得"应该不会走到这里"，但match 不这么认为——它要求你负起全责。

正确的处理方式有三种：

• 补全所有已知类型：加上 'NULL' => '', 'array' => json_encode($input)
• 或者用 default 统一兜底：default => throw new InvalidArgumentException("Unexpected type: " . gettype($input))
• 更推荐的做法：用 is_string()、is_int() 等函数做语义判断，而不是依赖 gettype() 的字符串匹配——后者在严格模式下更容易触发遗漏

array_key_exists(null, $arr) 突然失效？不是失效，是不再容忍

如果你还习惯性地把 null 作为 key 传给 array_key_exists()，那你很快就会收到一个 TypeError。PHP 8.0 开始，第二个参数必须是数组，第一个参数不能是 null。老版本里传入 null 会静默返回 false，现在直接抛出异常。

两种典型误用：

• array_key_exists($_GET['id'] ?? null, $cache) —— 如果 $_GET['id'] 不存在，?? null 给出的就是 null
• 从 JSON 解码后未经校验，直接把可能为 null 的值当 key 用

修复思路：

• 先确保 key 是标量：$key = $_GET['id'] ?? ''; if (!is_scalar($key)) { $key = ''; }
• 改用 isset($arr[$key])——但要注意它不区分 0、false、'' 的区别
• 在关键路径上加断言：assert(is_string($key) || is_int($key), 'Key must be scalar');

总结

类型收窄不是语法糖，也不是"帮你修补代码"的魔法。它是一条执行时的硬性拦截线，专门用来把那些"本来就有问题、只是没报错"的写法揪出来。

最难被发现的陷阱往往不是代码本身，而是我们的心理惯性：你以为自己处理的是"空字符串"，实际上拿到的是 null；你以为 ?? 已经做了兜底，但它改变不了后续函数的参数类型契约。所以，真正的安全不是在出事后补救，而是在编码时建立对类型的敬畏心。这才是类型收窄之后，开发者最需要补的一课。