php 8.0 起，为提升类型安全性，大量内置函数在接收到类型不匹配参数时由发出警告（e_warning）改为抛出 typeerror 异常；该变更依据 rfc “consistent type errors” 实施，并覆盖绝大多数类型敏感的内置函数，而非仅限 array_column() 或 count() 等个别函数。
php 8.0 起，为提升类型安全性，大量内置函数在接收到类型不匹配参数时由发出警告（e_warning）改为抛出 typeerror 异常；该变更依据 rfc “consistent type errors” 实施，并覆盖绝大多数类型敏感的内置函数，而非仅限 array_column() 或 count() 等个别函数。
PHP 8.0 引入的重大类型安全改进之一，是将原本仅触发 E_WARNING 的参数类型错误，统一升级为可捕获、可中断的 TypeError 异常。这一变更并非零星修补，而是系统性重构——其核心依据是 RFC: Consistent Type Errors，目标是实现“所有内置函数在类型不匹配时行为一致”。
✅ 影响范围：
- 并非仅限两个函数：尽管 count() 和 array_column() 是最常被提及的典型示例（因它们在旧代码中极易因传入 null 或非数组值而暴露问题），但实际受影响函数远超此数。
- 覆盖绝大多数类型敏感函数：包括但不限于 strlen(), strpos(), substr(), json_encode(), file_get_contents(), date(), sprintf(), in_array(), array_keys(), implode() 等数百个函数。只要函数签名明确声明参数类型（如 string $str, array $array），且调用时传入了不兼容类型（如向 strlen(null) 传 null，或向 date('Y-m-d', 'invalid') 传字符串而非时间戳），均会抛出 TypeError。
? 如何验证某函数是否受此变更影响？
最权威的方式是查阅 PHP 源码中对应函数的实现。关键线索在于函数定义中是否包含 Z_PARAM_* 类型校验宏（如 Z_PARAM_STRING, Z_PARAM_ARRAY），以及是否启用 ZEND_PARSE_PARAMETERS_THROW（该标志启用后即触发异常而非警告）。例如：
// PHP 源码片段示意（简化）
PHP_FUNCTION(strlen)
{
zend_string *str;
ZEND_PARSE_PARAMETERS_START(1, 1)
Z_PARAM_STR(str) // ← 此处校验强制为 string；PHP 8.0+ 默认抛出 TypeError
ZEND_PARSE_PARAMETERS_END();
RETURN_LONG(ZSTR_LEN(str));
}⚠️ 迁移注意事项：
-
运行时风险显著升高：过去 count(null) 返回 0 并触发警告，PHP 8.0+ 则直接 throw TypeError，若未被 try/catch 捕获，将导致脚本终止。
立即学习“PHP免费学习笔记（深入）”；
静态分析工具局限：多数 LSP 或 PHPStan/psalm 在默认配置下无法完全覆盖此类动态类型错误，需结合运行时测试与 --report-all 模式强化检测。
-
推荐防御性写法：
// ❌ 不安全（PHP 8.0+ 可能崩溃） $len = strlen($input); // ✅ 安全（显式类型检查 + 降级处理） if (is_string($input)) { $len = strlen($input); } else { $len = 0; // 或抛出自定义异常/记录日志 }
? 获取完整函数列表的方法：
官方未提供“一键清单”，但可通过解析 RFC 对应的合并 PR php/php-src#3794 中修改的 .c 文件（尤其是 ext/standard/, ext/json/, ext/date/ 等目录下的函数实现）批量提取。社区已有脚本化工具（如 php-typeerror-list）自动解析该 PR 并生成 CSV/JSON 格式对照表，建议在大型迁移项目中集成使用。
总之，PHP 8.0 的 TypeError 变更是深度、广泛且不可逆的底层行为升级。开发者应摒弃“仅修两个函数”的侥幸心理，转而采用类型断言、参数预检和全面回归测试，方能稳健完成升级。
