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 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
立即学习
“
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 指南”管用得多。
