php 8.5 并不存在，官方最高稳定版为 php 8.3，8.4 处于 rc 阶段；需重点关注 php 8.2 标记废弃、8.3 彻底移除的特性，如 assert() 字符串参数、mbereg* 函数、mysqli::change_user() 第三参数等。
PHP 8.5 并不存在，别被版本号骗了
PHP 官方目前（截至 2024 年中）最高稳定版本是 PHP 8.3，PHP 8.4 已进入 RC 阶段，但 PHP 8.5 尚未发布，也无任何官方路线图或 RFC 提及该版本。所谓“PHP 8.5 废弃特性”属于误传——你可能看到的是测试分支、第三方博客臆测，或是把 PHP 8.2 或 PHP 8.3 的废弃项记混了。
PHP 8.2 和 8.3 真正废弃/移除的功能有哪些
实际迁移中真正要处理的，是 PHP 8.2 开始标记为 DEPRECATED、并在 PHP 8.3 中彻底移除的特性。这些才是上线前必须检查的硬性变更点：
-
mysql_connect()等旧 MySQL 扩展函数早在 PHP 7.0 就已移除，但仍有遗留代码误用——它们和 8.2/8.3 无关，纯属历史债务 -
assert()的字符串参数形式（如assert('is_int($x)')）在PHP 8.2起触发E_DEPRECATED，PHP 8.3直接报E_ERROR；必须改用布尔表达式：assert(is_int($x)) -
get_magic_quotes_gpc()、get_magic_quotes_runtime()在PHP 8.3彻底消失——这两个函数自 PHP 5.4 起就已废弃，但直到 8.3 才删干净 -
mysqli::change_user()的第三个参数$database在PHP 8.3被移除，调用时若传入会报ArgumentCountError -
mb_ereg_replace()系列函数（mb_ereg、mb_eregi等）已在PHP 8.2标记废弃，PHP 8.3移除，必须迁移到mb_preg_replace()或原生preg_replace()+mb_*编码处理
如何快速定位自己项目里踩了哪些坑
靠人眼扫代码不现实，得靠工具和运行时反馈：
- 把
error_reporting设为E_ALL | E_DEPRECATED，在开发环境打开所有警告，真实请求一跑，废弃调用立刻暴露 - 用
php -l只能检查语法，没用；换成phpstan或psalm配合 PHP 8.3 stub，能静态识别很多已移除函数调用 - 搜索项目里出现的关键词：
mysql_、magic_quotes、mb_ereg、assert(.*['"]（正则匹配带引号的 assert 参数） - 注意 Composer 依赖：有些老包（比如某些
smarty旧版、phpexcel衍生库）内部还在用mb_ereg，升级它们比改自己代码还急
迁移时最容易忽略的隐性兼容问题
废弃函数只是表象，底层行为变化更难察觉：
立即学习“PHP免费学习笔记（深入）”；
-
json_encode()对NaN和INF的处理在PHP 8.3更严格，默认直接报错，而之前是静默转成null；如果业务逻辑依赖这个“宽容”，得提前加JSON_PARTIAL_OUTPUT_ON_ERROR -
DateTime构造时传入空字符串或null，在PHP 8.2+会抛ValueError，不再是返回 false 或当前时间 - 扩展加载顺序影响：比如同时启用
opcache和xdebug，某些废弃函数的错误提示可能被 opcache 缓存跳过，导致本地开发不报错、线上才崩
版本号别信虚的，盯紧 PHP 8.3 的实际变更清单，跑起来看错误，比查“8.5 指南”管用得多。
