PHP 5.6 环境踩坑实录：老版本维护常见问题与排查思路

最近在维护几个祖传项目的时候，环境还是死磕在 PHP 5.6 上。虽然大家都知道这版本早就凉了，但有些老系统牵一发而动全身，一时半会儿还真升级不动。这两天折腾的过程中遇到了一些让人头秃的问题，今天特意把排查过程和解决思路复盘一下，希望能帮到同样被困在老版本坑里的兄弟。

常见问题现象

很多时候，问题往往不是一开始就报错，而是间歇性地抽风。比如页面加载卡死、某些特定扩展调用失败，或者是直接 500 但日志里毫无痕迹。特别是 5.6 这种老版本，在很多新的 Linux 发行版或者 OpenSSL 更新后，特别容易出现依赖库不兼容的情况。

这里我们重点归类几个最常见的坑：

OpenSSL 版本冲突：这是最频发的。系统通过包管理器更新了 OpenSSL，导致老版 PHP 编译时链接的库版本过旧，运行时报类似 openssl_pkcs7_sign 或者 SSL 握手失败的错误。
依赖的动态库失效：比如 libcurl, libxml2 等底层库升级后，PHP 扩展莫名崩溃。
时间区域设置警告：虽然不致命，但往往充斥着日志，容易掩盖真正的错误信息。

遇到问题别慌，既然是老环境，就得用老办法来治。

首先，不要只看 Web 服务器的错误日志。很多时候 Nginx 或 Apache 只会甩给你一个通用的 500 错误。你需要直接去 php-fpm 的 error_log 里看细。

如果你开启了 display_errors，屏幕上大概率会有一些类似 Call to undefined function 或者 openssl 相关的警告。如果日志里是空的，尝试在入口文件强制开启错误输出：

ini_set('display_errors', 1);
error_reporting(E_ALL);

如果涉及到curl 请求或者加密相关的操作报错，大概率是这里的问题。

可以使用 php -m | grep openssl 确认模块是否加载。接着写个脚本检查一下当前的 OpenSSL 版本信息：

<?php
var_dump(openssl_get_version());
?>

如果这里的版本和系统上的 openssl version 对不上，或者极其老旧，那么你需要考虑重新编译 PHP 或者通过 pecl 安装更新版本的 OpenSSL 扩展（如果 5.6 还有支持的话）。

临时解决方案： 如果是生产环境且不能重启，可以尝试在请求时强行禁用部分验证（仅作排查使用，不推荐上线）：

stream_context_set_default([
    'ssl' => [
        'verify_peer' => false,
        'verify_peer_name' => false,
    ]
]);

Linux 下可以使用 ldd 命令检查 PHP 二进制文件或者对应的 .so 扩展文件依赖的库是否完整。

比如：

ldd /usr/local/php56/lib/php/extensions/no-debug-non-zts-20131226/openssl.so

如果看到有 not found 的输出，说明系统缺少该库，或者库路径变了。这时候通常需要重建软链或者安装对应的 dev 包。

虽然我们能修 Bug，但 PHP 5.6 即使修补了也是强弩之末。如果在排查过程中发现环境依赖已经乱成了一锅粥，比如系统升级到了 glibc 2.28+ 而 PHP 5.6 根本无法运行，这时候不要再硬修了。

推荐方案： 使用 Docker 镜像。官方仓库里甚至还有不少基于 Alpine 制作的 PHP 5.6 镜像，虽然底包老点，但胜在环境隔离，不会随着宿主机的 apt upgrade 而崩坏。

老版本维护就是一场和时间的赛跑。遇到问题先看依赖，再查日志，实在不行就上 Docker 容器化。如果有遇到其他稀奇古怪的报错，欢迎评论区交流，大家一起抱团取暖。