PHP调试总卡壳？3步精准定位90%隐藏Bug
|
去年5月，后台系统上线前两天，测试提了条用例：「导出Excel失败，但前端没报错」。我盯着控制台那行Notice: Undefined index: data in /app/export.php on line 47看了三分钟——不是看不出来，是它根本不该出现在这里。这行 Notice 早该被 error_reporting 屏蔽掉，而 error_reporting 早在入口文件里设成了 E_ALL & ~E_NOTICE。白板上还留着三天前跟后端对齐的 session 共享方案，粉笔字被蹭花了半边，底下压着张没撕干净的便利贴，写着「export.php 模块已走完 Code Review」。 先扔结论后补细节：90% 的 PHP 隐藏 Bug，卡在你没真正看清它在哪吐的第一口。不是 Xdebug 断点没打对，是断点打得太晚；不是日志没开，是日志往哪写、谁在读、读没读全，你全没确认过。导出功能崩了？先别查 foreach 里那个 $row['price']，先去 var_dump($_SESSION) ——结果发现 session_id() 跟 $_COOKIE[PHPSESSID] 对不上，再翻 Nginx 配置，发现 upstream 里少了个 sticky cookie 指令，session 其实根本没进对的 worker 进程。键盘上 Alt 键早掉了，只剩个塑料底座凸着，我每次想切终端都误按成 Esc，浏览器就跳出全屏模式。 第一步：锁死入口。不是看 index.php，是看 php-fpm 的 access.log 最后三条记录，比对 timestamp 和请求 path。那次我查到 /export.php 请求全进了 10.2.3.8 这台机子，而其他接口分散在四台，查 top 发现它 load 高得离谱，ssh 进去 tail -f /var/log/php-fpm/www-error.log，里面埋着一条重复 include 的 warning，路径拼错了，指向了一个不存在的 vendor/autoload.php.bak ——因为上周部署脚本里有个 sed 命令把 .bak 当关键词全替换了，连带改了 prod 环境配置。没人去拿的外卖袋挂在门把手上，纸袋边缘已经软塌塌地垂下来，汤渍渗出一圈淡黄印子。 第二步：截住输出流。别信 echo、print_r，直接在出口前加 ob_start(); register_shutdown_function(fn() => file_put_contents('/tmp/output.log', ob_get_contents()));。那天导出数据明明查出来了，CSV 却空，我这么一搞，/tmp/output.log 里第一行赫然是 <?php header('Content-Type: text/csv'); ——前面被某段异常终止的 PHP 输出硬塞进了 header 之前，导致 Content-Type 失效，浏览器当 html 解析，当然下不了 CSV。控制台报错栏里第47行下面还堆着两行红色 Warning，但它们全被 header 已发送的 fatal error 盖住了。会议室空调出风口正对着工位，吹得竖着的显示器屏幕微微反光，看 git log 都要歪头避开光斑。
文章配图，仅供参考 第三步：回溯依赖链。不是从当前文件往上 require，是顺着 composer.lock 找真正被加载的包版本，然后 grep -r 'function_name' vendor/ 。导出逻辑调用了 spout 的 ReaderFactory，但 lock 文件里锁定的是 v3.3.0，而文档写的是 v4+ 才支持 .xlsx 的 streaming 模式。我手抖在 config 中写了 'format' => 'xlsx'，其实底层 fallback 到了 CSV，却没触发任何 warning ——因为 Spout 在 3.x 版本里把 format 错误当静默降级处理了。设计稿标注里写的「导出按钮禁用态灰度 #ccc」，实际开发时我把 class 写成了 export-btn--disabled，但 CSS 文件里只定义了 .export-btn[disabled]，所以按钮点了没反应、首屏转圈、控制台一片红，三个现象根本不在一个栈里。有人端着杯子站了很久，在我身后看我切 terminal 标签页，杯沿水汽凝成小珠，滴到我键盘 F12 键旁边的缝隙里。他最后说：「要不要试试把 error_log 改成 syslog？」我没接话。这种事试不得——log 日志轮转配错过一次，/var/log/messages 就被 php 错误刷爆过两次，第二次我们凌晨三点在生产机上删日志，删到一半 rsync 同步任务把备份盘也占满了。后怕？不。是记住了：下次动 error_log，先 check rsyslog 的 /etc/rsyslog.d/50-default.conf 里有没有 $MaxMessageSize，再看 /proc/sys/net/core/somaxconn 是多少。这些数字不会自己跳出来喊你。 现在我 debug 前，必做三件事：1）先 tail -f 两个日志（php-fpm 的 www-error 和 nginx 的 access），2）在入口处强制 ob_start()，3）打开 Xdebug 的 remote_log，把调试协议原始帧存下来——不是为了分析，是为了确认 Xdebug 是否真的连上了，还是只是 IDE 在假装断点生效。这次导出问题的根因，最终定位在部署机的一次未提交的本地 patch，覆盖了 vendor/spout/src/Reader/CSV/RowIterator.php 的第67行：把 while($this->hasNext()) 改成了 while(true)，理由是「修复超大文件读取性能」。没人 review 过，没人测过，就跟着 deploy.sh 一起上了生产。我把它 revert 了，rebuild 了一次镜像，推上去，导出正常。没写 PR，没走流程，只在 GitLab CI 流水线的 deploy-job 下面加了句注释：// 临时绕过 spout patch bug，已联系 maintainer，等待新 tag。这事儿我不打算再碰了——下周一我要去看那个客户投诉「H5 分享图黑屏」的问题，截图里背景图 URL 是 https://cdn.xxx.com/sharebg.png?v=20240518，而 CDN 缓存规则里明确写了 png 不缓存，但 cache-control 响应头里却是 public, max-age=31536000。我得去翻 Nginx conf，看看是不是 upstream 的 set $cdn_host 没生效，或者 proxy_cache_key 里漏了 $scheme。 （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
