可行但需分层验证与精准替换：先确认7.4项目是否含create_function等8.0已移除函数、动态类型误用、json异常处理等风险点，再完成环境配置、扩展验证、依赖检查，重点修复mb_strpos参数类型、enum类名冲突、json_encode输出突变等高频问题，最后用真实流量压测。
直接从 PHP 7.4 升到 8.3 是可行的，但不是“装完就跑”，关键在于控制风险、分层验证、精准替换。很多项目卡在升级半途，不是因为语法太难，而是跳过了几个必须动手检查的环节。
先摸清底子：确认你的7.4到底“多老”
PHP 7.4 本身已非常接近 8.0，但项目实际用法可能远超版本表象。重点看三类内容：
- 是否用了
create_function()、each()、mysql_connect()等早在 7.2/7.3 就被标记废弃、8.0 彻底删除的函数——这些一运行就 Fatal Error - 是否依赖未声明类型的动态行为，比如把字符串当数组访问（
$str[0]）、用array_key_exists()判断对象属性（8.0+ 不再触发__isset()） - 是否自定义了
json_encode()行为，或对 NaN/INF 做了特殊处理（8.0+ 默认返回null，且静默忽略非法 UTF-8）
改代码前必做两件事
别急着改业务逻辑，先让环境和工具准备好：
- 在本地或测试服务器装好 PHP 8.3，并确保
php -v和php --ini显示的是你预期的路径和配置；用php -m检查扩展是否加载，再用php -r "echo json_last_error_msg();"验证 JSON 模块是否正常 - 运行
composer update --dry-run，看是否有包声明"php": "^7.2"却没兼容 8.x；同时执行composer check-platform-reqs，确认所有扩展（如 redis、xdebug、gd）都支持 8.3
重点替换四类高频崩点
这四类问题覆盖了 80% 的升级失败场景，改一处，验一处：
立即学习“PHP免费学习笔记（深入）”；
-
mb_strpos 第三个参数必须是 int：旧代码里
mb_strpos($s, 'x', strpos($s, 'y') / 2)在 8.0+ 会报TypeError，统一加(int)强转，例如mb_strpos($s, 'x', (int) (strpos($s, 'y') / 2)) -
create_function 彻底消失：不能替换成
eval()，应改为箭头函数（fn($a) => $a * 2）或普通匿名函数（注意用use显式传入外部变量） -
enum 类名冲突立即报错：如果已有
class Status或interface Type，又想用enum Status，必须先重命名旧类（如class LegacyStatus），否则编译不过 -
json_encode 输出突变：含中文乱码、特殊符号或 NaN 的字段，在 8.0+ 可能变
null或被截断。建议升级后加日志：var_dump(json_last_error(), json_last_error_msg())，再针对性加JSON_UNESCAPED_UNICODE | JSON_INVALID_UTF8_SUBSTITUTE控制输出
上线前最后一道关：用真实数据过一遍
单元测试和静态分析（如 PHPStan level 6+）能发现语法和类型问题，但真实请求链路里的坑还得靠数据压出来：
- 把生产环境最近一天的典型请求日志导出，用脚本回放核心接口（如登录、下单、导出），观察是否出现新 Warning 或 TypeError
- 特别关注带文件上传、富文本内容、第三方回调参数的接口——这些地方最容易藏非法 UTF-8 或浮点 offset
- 数据库字段值若含 \0、\xFF 或其他非 UTF-8 字节，
json_encode()在 8.3 会静默丢弃后续内容，前端看到的就是“字段突然没了”
