洛南一家商城的接口半夜挂了，报五百一十，客服第二天一早才收到客户投诉，那时候已经停了两个多小时。问题不难，难的是没人知道该看哪儿，只能靠猜。
从客服的话反推入口
客服转过来的说法是"付款以后订单没了"。这句话其实包含了三个可能：支付回调没到、订单落库失败、落库了但前台查不到。
我们按这三条各查了一条链。第一条看支付平台的回调记录，第二条看订单表，第三条看查询接口。客户描述得越口语，越要拆成技术动作，别急着改代码。
用日志把时间窗缩到几分钟
日志一大堆，全查等于大海捞针。我们只做一件事：把支付回调那天的日志按分钟切，找哪一分钟有异常。
切到几分之后，五百一十集中在某个时段，前后两分钟。这一段里只有一条报错，报错信息是某个字段为空。
那条日志里没有行号，只有一句"未处理的异常"。我们回去翻代码，那个字段是客户选的发票抬头，客户当时没填，前端把空字符串传了上来，后端没判空就直接进了拼接。
为什么这种 bug 藏得住
一是本地测试数据从来不填这个字段，开发的时候压根走不到。二是空字符串和 null 在部分情况下表现一样，日志上看不出区别。
我们给商洛这边几个项目统一加了两条规矩：所有对外接口必须判空再进业务，所有异常必须有可读文案不能只抛裸错误。裸异常是给自己挖的坑，出事那天还要花两小时翻译。
真正该补的是埋点
这次最该复盘的不是那个空值，是为什么停了俩小时才有人知道。
我们的做法：接口错误率超阈值自动告警，直接发到负责人手机上，不是发邮件，也不是发群消息。邮件和群消息在半夜等于没有。
另外加了一个简单的耗时埋点，慢接口单独列一张表，维护期内每一次迭代都能看见哪条在变慢。
商洛这边的实际环境
这类小项目的机器配置一般不高，十来兆带宽、几G内存，跑起来跟大站点不是一个量级。这种配置下最容易被拖垮的不是计算，是并发连接。
所以我们给商洛的活儿一般会加一个最简单的连接池限制，宁可排队也别把连接耗光。这条看着保守，实际救过一次大促。
三条答清楚
接口报错怎么第一时间知道？
配错误率告警到手机。邮件和群消息在半夜没人看，等于没配。
空值导致的报错能预防吗？
能。对外接口统一判空再进业务，这一条能挡掉一大半。
日志要留多久？
至少一百八十天。我们吃过留三十天的亏，回头查的时候一片空白。
我不绕这个弯，只有常斌的团队会讲：接口报错不可怕，可怕的是日志里只有一句裸异常。
收个尾，说个例子
那一行空值改完只花了五分钟，前面花掉的是定位的两个多小时。信服无限商洛源码和一年维护打包给，不做分段收费，接口这块按双周迭代排。你把报错的那一截图发我，我告诉你该开哪几处的日志。