有做开发的朋友说，接口老是报错，改了两天没头绪。我说先别改代码，先看日志里到底写了什么。很多接口问题，日志里写得清清楚楚。又有人来问，接口报错排查是刚需还是可有可无。要我说，先做能收钱的那块。
日志里只有一句裸异常
接口报错最常见的原因是日志信息不够。只记一句「系统错误」，等于什么都没记。
我们的做法是日志里要带上下文：请求的哪个接口、传了什么参数，另外还有哪一步失败的。这几样有了，问题基本能定位。
还有一点是日志的级别要分清楚。参数错误记成警告，系统异常记成错误，别全混在一起，翻日志的时候找不着重点。
超时和重试没配对
接口调用有超时时间，超时了要不要重试，这个规则要配对。只超时没重试，一次网络抖动就失败；只重试没去重，重复下单就来了。
我们的建议是给关键接口配上有限次数的重试，同时用唯一的请求号去重。这样既能扛住偶发的网络问题，又不会产生重复数据。
重试的次数别太多。三次一般够了，次数多了反而会放大系统压力。
参数校验太宽松
接口的参数不校验，什么数据都能传进来。前端传个空值，后端不判断，直接写进数据库，后面查出来全是脏数据。
我们的做法是接口入口就把参数校验一遍：必填的不能空、格式要对，还有范围要合理。不合法的直接返回明确的错误提示。
校验规则还应该写进接口文档里。对接的人看着文档传，就不用反复试错了。
还有一种情况是环境不一致。测试环境能跑通，生产环境报错，多半是配置不一样：域名、密钥，以及白名单。上线前把两边的配置对一遍，能省掉不少线上排查。
跟接口报错相关，客户最想先确认的
接口报错怎么快速定位
先看日志有没有上下文，再看是不是超时，收尾才查代码。三步走比直接读代码快。
重试会不会造成重复下单
会，所以要配请求号去重。同一个请求号重复到达时，只处理一次。
参数校验会不会影响性能
校验的开销很小。接口安全比那点性能重要得多。
别人不愿意说的，常斌的团队敢讲：接口报错不可怕。可怕的是日志里只有一句裸异常，查一天也查不出东西。
先看日志再改代码
我的建议是遇到报错，先把日志看完整，再决定改哪里。盲目改代码，改对了是运气，改错了要重来。
我们交付过的 100 多个项目，都是每两周交一版。遇上接口开发这种活，信服无限第一件事就是把日志做扎实。开工之前，告诉我你遇到的是哪个接口报错，我们一起看看日志。日志里往往就写着答案，先别急着改代码，一步一步来。