php 8 升级需主动排查不兼容项：strlen(null)等调用直接报错；用php -l、phpcs和grep定位隐患；each()、create_function()等已移除；assert()、mb_*()等行为剧变；第三方依赖和扩展须确认php 8支持。
PHP 7 升级到 PHP 8 不是“换版本就能跑”，很多项目上线后直接 Fatal error 或满屏 TypeError，根本原因不是你代码写错了，而是 PHP 8 把过去“容忍”的行为变成了“拒绝”——比如 strlen(null)、count(null)、array_key_exists(null, $arr) 这类调用，在 PHP 7.x 里可能只警告或返回默认值，PHP 8 直接报错中断。
怎么快速定位不兼容代码
别等上线崩了再查，本地就能筛出 90% 的隐患：
- 用
php -l批量扫描：运行find ./app -name "*.php" -exec php -l {} \; 2>&1 | grep -E "(Deprecated|Warning|Fatal)"，重点盯Deprecated和Fatal error行 - 加临时错误报告：在入口文件开头插入
error_reporting(E_ALL | E_STRICT); ini_set('display_errors', '1');（仅开发环境） - 用静态分析工具：装
phpcompatibility/php-compatibility，执行phpcs --standard=PHPCompatibility --runtime-set testVersion 8.0 ./app，它会标出each()、create_function()、命名参数混用等明确不支持项 - 全局搜高危模式：用
grep -r ":[a-zA-Z]" app/ --include="*.php"找命名参数混用（如foo("x", bar: true)），PHP 8 禁止这种写法
哪些函数和写法必须改
以下不是“建议替换”，而是 PHP 8 中已移除或行为剧变，不改就报错：
-
each()：已被彻底移除。不能简单替换成key()/current()循环，因为指针管理逻辑不同；正确做法是统一用foreach ($arr as $k => $v) -
create_function()：已移除。改用匿名函数：function($a) { return $a * 2; }或 PHP 7.4+ 的箭头函数：fn($a) => $a * 2 -
assert()字符串参数：PHP 8 默认开启assert.exception = 1，assert('is_int($x)')会尝试执行字符串并抛异常；必须改为布尔表达式：assert(is_int($x)) -
mb_*()缺省编码：PHP 8 强制要求显式传$encoding参数，否则警告；统一补上'UTF-8'，例如mb_strlen($s, 'UTF-8') - 构造函数中未声明类型的参数：如果类里有
public function __construct($id)，而后续又用了$this->id，PHP 8 会报Undefined property；要么加属性声明public int $id，要么用属性提升public function __construct(private int $id)
第三方依赖和扩展最容易翻车
框架和扩展不升级，光改自己代码也没用：
- 检查 Composer 依赖是否声明支持 PHP 8：运行
composer check-platform-reqs，看有没有包卡在php: ^7.4；特别注意laravel/framework 、<code>thinkphp/framework 、<code>symfony/* 这些老版本根本不适配 - 扩展版本要对得上：Redis 必须 ≥
5.3.0，GD ≥2.3.0，否则php -m会报加载失败；igbinary等小众扩展在 PHP 8.7 前仍无稳定版，得查清兼容矩阵再动 - 别信“兼容写法”：比如用
#[\ReturnTypeWillChange]压制IteratorAggregate::getIterator()报错，这只是临时绕过，对应组件必须升级，否则迟早出问题 - 配置
"platform": {"php": "8.1"}到composer.json，防止composer install拉入不兼容的旧版依赖
match 表达式和类型边界最易被忽略
这两个地方不会立刻报错，但逻辑会悄悄变，上线后难排查：
-
match()是严格比较：match ($x) { 1 => 'int', '1' => 'string' }，传入字符串'1'只走'1'分支；而旧switch是松散比较，可能命中1。所有从$_GET、JSON、数据库读出来的值，进match前务必确认类型，用var_dump(gettype($x), $x)实测 - 联合类型声明后，返回
null就算错：function foo(): string|int里不能return null；要么改成string|int|null，要么加判空逻辑 -
__toString()方法必须返回string，返回int或null在 PHP 8 直接Fatal error；老项目常在这里埋雷，尤其 ORM 模型的 toString 逻辑 -
fn()箭头函数不能访问$this，也不能use动态变量；若原代码混用function() use ($x)和fn()，作用域不一致会导致结果错乱
真正难的不是改语法，而是那些没报错但行为已变的地方——比如 trim(null) 在 PHP 8.1+ 抛 TypeError，而你测试时传的全是非空字符串；边界输入不覆盖，上线遇到脏数据就崩。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
