PHP批量升级须按站点逐个验证切换，通过FPM多池隔离、静态分析（phpstan）、三处配置核查及运行时断点测试（登录态、文件上传、cron）确保兼容性。
PHP 版本过低不是单个站点的问题，而是服务器上多个站点共用旧版 PHP 运行时导致的批量兼容风险——直接全局升级 PHP 极易引发 Parse error、Deprecated 或扩展缺失报错，必须按站点逐个验证+切换，不能“一刀切”。
确认哪些站点实际在用低版本 PHP
别凭印象判断。很多站点看似没动，其实早已被 phpinfo() 或 .user.ini 锁死在 5.6/7.0；有些则靠 ini_set() 强行绕过配置，但新版 PHP 已移除这些函数。真实情况要查三处：
-
/etc/php/*/apache2/php.ini和/etc/php/*/cli/php.ini中的display_errors和error_reporting是否开启，方便后续捕获报错 - 每个站点根目录下是否存在
.htaccess（Apache）或nginx.conf片段中硬编码了SetHandler "proxy:unix:/var/run/php/php5.6-fpm.sock|fcgi://localhost"这类路径 - 运行
grep -r "php_version\|PHP_VERSION\|version_compare" /var/www/*/ --include="*.php"找出显式依赖旧版语法（如mysql_connect()）或常量的文件
用 PHP-FPM 多池隔离 + 按站切换版本
Apache 或 Nginx 本身不决定 PHP 版本，真正起作用的是后端连接的 FPM socket。批量升级的核心是让不同站点指向不同 php-fpm 实例，而非改全局配置。
- 为每个目标 PHP 版本启用独立服务：运行
systemctl enable php7.4-fpm、systemctl enable php8.1-fpm，再systemctl start它们 - 每个站点的虚拟主机配置里，把
fastcgi_pass（Nginx）或SetHandler（Apache）指向对应版本 socket，例如unix:/var/run/php/php8.1-fpm.sock - 不要复用同一份
www.conf：复制/etc/php/8.1/fpm/pool.d/www.conf为site-a.conf，修改其中listen = /var/run/php/php8.1-fpm-site-a.sock和php_admin_value[open_basedir]限定该站点根目录
批量检测兼容性：用 phpstan + 自定义脚本筛硬伤
人工翻代码效率低，且容易漏掉 create_function()、each() 这类 PHP 7.2+ 废弃函数。用静态分析快速定位高危点：
网胜B2B电子商务系统红色风格 2008 SP6.2 普及版
下载
网胜B2B电子商务系统SP6.2红色风格普及版本升级功能说明：1、邮件群发功能：可以选择某一级别的会员，并放入支持html编辑器的文本内容，进行有选择的对会员进行信息群发。2、网站整站访问统计：可以通过后台进行网站前台访问量的常规统计以及流量查看。3、对注册的会员进行ip记录，可以跟踪客户的所在位置。4、得新对前台的所有信息排序进行重新调整。5、对会员注册页面进行防批注加强，加入更多的ajax技术
立即学习“PHP免费学习笔记（深入）”；
- 安装
phpstan/phpstan后，对每个站点执行：phpstan analyse --level 0 --configuration=phpstan.neon /var/www/site-a/，重点关注Function create_function not found类报错 - 写一个轻量脚本扫描
eval(、mysql_、mysql_pconnect、mysqli::set_charset（注意：PHP 8.1 移除了mysqlnd的部分 charset 方法） - 特别留意 Composer 依赖：运行
composer show --outdated，若monolog/monolog是 v1.x，它在 PHP 8.1 下会因__toString()返回类型不一致而 crash
上线前必须验证的三个断点
即使静态检查全绿，仍可能在运行时崩。以下三点不验证，等于没升级：
- 登录态是否断裂：检查
session.cookie_httponly、session.cookie_samesite在新 PHP 中默认值变化，老站点若没显式设SameSite=None，Chrome 80+ 会丢 Cookie - 文件上传是否失败：PHP 8.0+ 默认禁用
file_uploads = Off？不，但post_max_size和upload_max_filesize若单位写成20M（而非20MB），新版解析会失败并静默截断 - cron 脚本是否还在跑：
php /var/www/site-a/cron.php这类命令行调用，用的是 CLI SAPI，其配置文件是/etc/php/*/cli/php.ini，和 Web 不共用，极易被忽略
最麻烦的不是升级动作本身，而是旧站点里那些没文档、没测试、靠“一直能跑”维持的逻辑——它们往往藏在 cron、后台导出、微信回调等非主流程里。批量升级不是换版本号，是给每个站点做一次轻量级重构审计。
