升级 PHP 8.1 后接口变慢通常是因为 deprecated 警告触发了频繁的错误日志写入或自定义错误处理逻辑。最推荐的处理方向是定位具体警告代码并修复，临时方案可调整 error_reporting 级别，但需注意长期屏蔽可能掩盖潜在故障。
先说结论：PHP 8.1 废弃函数警告本身不直接消耗大量 CPU，但引发的日志 I/O 和错误回调会显著增加接口耗时。
- 先定位：检查 error_log 文件确认警告频率和类型
- 先做：修复代码中废弃函数调用或临时调整错误报告级别
- 再验证：对比调整前后接口响应时间和日志文件大小
命令速用版
通过以下命令快速查看错误日志或临时关闭警告输出，用于紧急止血。
# 查看实时错误日志
tail -f /var/log/php/error.log
# 临时在代码中关闭 deprecated 警告
ini_set('error_reporting', E_ALL & ~E_DEPRECATED);
为什么会这样
废弃警告导致变慢的核心原因是磁盘 I/O 开销和错误处理函数执行耗时。PHP 8.1 引入了多项废弃特性，当代码触发这些警告且配置为记录日志时，每次请求都会产生磁盘写入操作。
公开资料中没有看到可靠的量化数据表明具体慢多少，但高并发下频繁写日志会阻塞进程。此外，若项目注册了自定义错误 handler，每次警告都会执行回调逻辑，进一步增加 CPU 消耗。
分步处理
按以下步骤排查并解决警告导致的性能问题。
步骤 1：确认警告内容
查找 php.ini 中 error_log 配置路径，或使用 grep 搜索日志文件。
grep "Deprecated" /var/log/php/error.log | head -n 10
步骤 2：修复代码
根据日志提示的文件和行号，替换废弃函数。例如将 utf8_decode 替换为 mb_convert_encoding。
步骤 3：调整配置（临时）
若无法立即修复代码，可在 php.ini 或.user.ini 中调整 error_reporting，排除 E_DEPRECATED。
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
步骤 4：重启服务
修改配置后重启 PHP-FPM 或 Apache 使配置生效。
怎么验证是否生效
通过监控接口响应时间和日志增长情况确认优化效果。
检查点 1：接口耗时
使用 curl 或压测工具对比优化前后的平均响应时间。
time curl -o /dev/null -s -w "Time: %{time_total}\n" http://localhost/api
检查点 2：日志体积
观察单位时间内 error_log 文件大小的增长速度是否下降。
检查点 3：状态码
确认接口返回 HTTP 状态码仍为 200，未因错误处理逻辑变更而异常。
常见坑
- 生产环境开启 display_errors：会导致警告内容直接输出到响应体，增加网络传输开销且暴露路径信息。
- 完全屏蔽错误报告：长期关闭 E_ALL 可能导致其他严重错误被忽略，建议仅屏蔽 E_DEPRECATED。
- 忽略 null 值传递警告：PHP 8.1 对内部函数参数 null 值敏感，此类警告频率极高，需优先处理。
常见问题
废弃警告会影响业务逻辑吗
通常不会直接中断业务，但可能导致数据编码错误或函数返回意外值。PHP 8.1 的 deprecated 函数仍可运行，但未来版本会移除。
如何批量查找所有废弃函数调用
可以使用静态分析工具如 PHPStan 或 Rector 扫描代码库，配置级别为 PHP 8.1 以识别废弃用法。
临时屏蔽警告会影响后续升级吗
不会影响升级，但会掩盖代码兼容性问题。建议在测试环境尽快修复代码，生产环境仅作为短期止血手段。
参考来源
- PHP Official Documentation, Migration Guide 8.1, Deprecated features, https://www.php.net/manual/zh/migration81.deprecated.php