网站错误信息整改报告

昨天下午三点，网站用户老张在结算页面卡了整整七分钟。错误他反复点击“提交订单”，信息页面每次都在最后一步弹出一串乱码——SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded。整改这不是报告他第一次遇到这问题，但这次他直接截了图发到客服群，网站附带一句“你们网站是错误不是崩了”。客服同事转给我时，信息我盯着那行错误码，整改后背发凉——这已经是报告本月第四次同样的报错。

问题出在数据库连接池。网站订单服务和库存服务共用同一个MySQL实例，错误高峰期并发写入时，信息事务互相等待锁超过默认的整改50秒阈值，直接抛错。报告代码里没做重试机制，前端也没捕获异常，于是用户看到的就是裸露的数据库报错。更糟的是，错误信息里带着完整的SQL语句和表名——这对懂行的人无异于直接暴露了表结构。

我翻了近三个月的错误日志，发现这类“裸奔”错误占了总异常的38%。有的报错直接把服务器绝对路径打印出来，比如/var/www/html/app/Models/User.php，攻击者顺着路径能摸清项目结构。还有一次，支付回调接口因为第三方返回格式变更，直接吐了堆PHP警告，页面顶部冒出黄色提示条，用户还以为是钓鱼网站。

整改从两个层面下手。第一层是技术兜底：把数据库锁等待超时从50秒降到10秒，让事务快速失败而不是干等；同时给所有数据库操作加上重试机制，最多重试三次，每次间隔随机200-500毫秒，错开并发高峰。第二层是信息脱敏——写了个全局异常拦截器，任何未被捕获的异常都统一转成JSON格式，错误码用内部编号（比如E1001代表数据库锁超时），对外只显示“系统繁忙，请稍后再试”，真正的堆栈信息只记录到服务端日志，且日志里自动过滤IP、密码、token等敏感字段。

前端也改了。以前错误页面千篇一律是白底黑字加个“500 Internal Server Error”，现在分场景处理——网络超时提示“网络开小差了，检查下WiFi”，库存不足提示“这件衣服被抢光了”，数据库异常则提示“服务器正在努力恢复”。错误提示不再弹技术术语，而是给用户一个可操作的出口：要么返回首页，要么联系在线客服。

测试阶段最折腾。我们故意在预发环境模拟了死锁、慢查询、断网、第三方超时等十几种故障场景，结果发现重试机制本身有bug——当数据库连接池本身已满时，重试只会加剧拥堵。后来改成指数退避算法，第一次等200毫秒，第二次400毫秒，第三次800毫秒，最多五次，超了就降级到只读缓存。这个改动花了三天，但上线后效果立竿见影。

这周复查了线上日志，数据库类错误从每天平均47次降到3次以内，而且再没有一条错误信息泄露过SQL或路径。最让我意外的是，用户咨询量里关于“页面报错”的工单减少了近六成。老张昨天又下单了，这次他没截任何图，系统安静地处理完了整笔订单。

其实很多网站错误整改没做好，不是技术不够，而是没把用户当人看。用户看到“500”只会觉得这网站不靠谱，看到“数据库连接失败”只会更慌。把错误信息当朋友来写，该道歉道歉，该指路指路，比什么花哨的架构优化都直接。当然，底层的坑还是得填——毕竟再友好的提示，也比不上根本不出现错误。