PHP 7.3老项目维护需系统排查：先确认真实运行环境与配置，再结合错误日志、访问日志定位异常，优先扫描MySQL扩展兼容性、会话失效、上传异常、时区错乱等高频病灶，并联动安全检查eval/system等危险函数。
PHP 7.3 老项目维护中，问题往往不是突然爆发的，而是长期积累的逻辑混乱、配置偏差和安全裸露共同导致的。排查不能靠“试”，得有路径、有重点、有验证闭环。
先确认 PHP 实际运行环境与配置
很多看似代码问题的现象，根源在环境错配：
- 用
phpinfo()或php --ini查清当前生效的 php.ini 路径，别只改了备份文件或错误目录下的配置 - 检查
error_reporting和display_errors是否关闭——线上报错消失不等于没出错，可能只是被静默吞掉了 - 核对
date.timezone、memory_limit、max_execution_time等关键参数是否仍适配当前业务量（比如老项目设的 32M 内存，现在跑导出报表直接超限） - 确认扩展是否真实加载：
php -m | grep gd比看 phpinfo 页面更可靠，避免页面缓存误导判断
从日志入手定位异常源头
老项目最怕“凭感觉猜”，而日志是唯一客观线索：
- 查 PHP 错误日志（
error_log配置项指定路径），重点关注Warning和Notice——它们常是后续致命错误的前兆，比如未定义索引引发的数组操作失败 - 翻 Web 服务器访问日志（如 Nginx 的
access.log），筛选 500、404、413 状态码，对应到具体 URL 和时间点，再反查代码入口 - 若用 Apache + mod_php，注意
php_admin_value可能在虚拟主机配置里覆盖 php.ini，这类“隐藏配置”必须一并检查
快速识别典型老项目病灶
以下几类问题在 PHP 7.3 老项目中高频出现，可优先扫描：
立即学习“PHP免费学习笔记（深入）”；
-
MySQL 扩展兼容性：还在用
mysql_*函数？PHP 7.3 已彻底移除，必须替换成mysqli_*或 PDO；若用的是旧版 ThinkPHP 3.2、Dedecms 等，需确认是否打了兼容补丁 -
会话失效/登录态丢失：检查
session.save_path目录权限是否可写、session.cookie_httponly是否开启（防 XSS 窃取）、session.gc_maxlifetime是否过短导致频繁登出 -
上传功能异常：不只是
upload_max_filesize，还要同步调大post_max_size和max_input_time；老项目常忽略$_FILES['type']可伪造，导致恶意文件绕过检测 -
时区与时间函数错乱：大量使用
time()、date()却没设时区，会导致日志时间、订单生成时间、缓存过期全部偏移，排查时先加一行date_default_timezone_set('Asia/Shanghai');测试
安全与可维护性联动排查
老项目的问题常藏在“能用”表象下：
- 搜索全项目中的
eval(、system(、create_function() —— 这些是 Webshell 入口或历史遗留高危调用，PHP 7.3 中create_function已废弃，必须替换 - 检查所有文件上传点：是否仅校验扩展名？是否跳过
finfo_open()真实 MIME 检测？图像上传是否漏掉getimagesize()二次验证？ - 翻出最早期的配置文件（如
config.php），确认数据库密码、API 密钥等敏感信息是否硬编码在代码里，而非通过环境变量或独立配置文件管理
