PHP 7.3老项目排查核心是分层定位：先确认真实入口和执行环境，再锁定代码逻辑断点，接着检查依赖兼容性（如废弃函数、扩展缺失、框架不兼容），最后反向验证安全异常。
PHP 7.3 老项目维护中排查问题，核心不是“猜哪里坏了”，而是建立分层定位路径：从现象出发，逐级缩小范围，避免在错误层级浪费时间。重点不在版本新旧，而在逻辑链是否清晰、日志是否可用、依赖是否可控。
先确认真实入口和执行环境
老项目常存在多套入口混用（如 index.php、main.php、api/v1/index.php），或通过 .htaccess / nginx 重写隐藏真实路径。第一步要明确当前请求实际由哪个 PHP 文件响应：
- 在 Web 服务器访问日志中查该 URL 对应的脚本路径（例如 Apache 的 access_log 或 Nginx 的 access.log）
- 临时在疑似入口文件顶部加一行：
error_log("RUNNING: " . __FILE__, 4);，看错误日志里真正执行的是谁 - 检查 phpinfo() 输出的 Loaded Configuration File 和 Server API，确认是 CLI、Apache 模块还是 FPM 模式——不同模式下 php.ini 加载路径、扩展启用状态可能完全不同
快速锁定代码逻辑断点
老项目常见“改一处、崩三处”，是因为函数复用混乱、状态隐式传递。不要直接搜报错关键词，先做三件事：
- 用 grep -r "function login" . --include="*.php" 找出所有同名函数，比对参数签名和返回值，确认当前调用的是哪一个
- 在关键流程节点（如数据库查询后、条件判断前）加
error_log("STEP: user_id={$uid}, status={$status}", 4)，用日志串起执行流 - 禁用所有非必要扩展（尤其是 opcache、xdebug），用
php -d opcache.enable=0 script.php运行，排除缓存/调试器干扰导致的偶发异常
检查依赖与兼容性硬伤
PHP 7.3 虽已停止官方支持，但多数老项目卡在“能跑就行”，真正阻碍升级的是隐性依赖：
立即学习“PHP免费学习笔记（深入）”；
- 检查是否用了已被移除的函数：如 mysql_*() 系列（PHP 7.0 已彻底删除）、mcrypt_*（PHP 7.2 废弃，7.3 需手动编译）、create_function()（7.2+ 报 deprecated）
- 查看扩展是否加载成功：
php -m | grep -E "(gd|mbstring|curl|pdo)"，尤其注意某些老项目依赖 php-mcrypt 或 php-geoip，而 7.3 默认不带 - 验证第三方库兼容性：比如老项目用的 ThinkPHP 3.2 或 CodeIgniter 2.x，默认不兼容 PHP 7.3 的严格类型提示或废弃语法，需打补丁或锁定 Composer 版本
安全与异常行为的反向印证
很多“功能异常”其实是被攻击后的残留表现，不能只当 Bug 修：
- 检查上传目录是否有可疑文件：
find ./uploads -name "*.php" -o -name "*.phtml" -o -name "*.php3"，尤其注意文件修改时间是否集中在凌晨低峰期 - 扫描高危函数调用：
grep -r -n "eval\|assert\|system\|exec\|shell_exec\|base64_decode.*eval" . --include="*.php" - 对比正常与异常请求的 $_SERVER 变量差异，例如 HTTP_REFERER 是否为空、HTTP_USER_AGENT 是否含 sqlmap/curl 等特征，辅助判断是业务逻辑问题还是被扫描试探
