客户端需要给服务端兜底吗

前言

客户端向服务端请求一个点赞数，服务端出了bug返回一个负数，用户看到点赞数为负以后，反馈了这个bug。复盘的时候，服务端在总结了自己的问题之后问客户端，有没有设计过“收到的点赞数为负数”这条用例，用例的预期结果是直接展示出来么？为什么客户端收到这种异常输入没有做一个兜底？所以问题来了，客户端需要给服务端兜底么？

一个潜规则

最近我在一本书的评论区看到这样一个规则，我觉得总结的非常到位，并且这位开发工程师说这是他们项目组沿用了十几年的潜规则，非常好使。我在这里分享给大家，这个规则说的是“服务端错误直接报，客户端的报错可以做兼容处理，但也该把堆栈打到log中去”，什么意思呢？服务端面对的是客户端，大家自己人，有话直说，报错越清楚，越方便排查问题。比如客户端调一个接口，服务端报错，返回错误码“500”，错误信息”数据库连接失败“。这就非常清晰，非常容易排查问题。而客户端面对的是用户，说话就得含蓄，就要考虑用户体验。客户端把”错误码500和数据库连接失败“直接透出给用户就很不合适，客户端应该做一个兼容让用户看着舒服。怎么兼容能让用户舒服是一个产品策略问题，可以和产品经理一起讨论决定。最后，由于做过兼容前端已经看不出来错误的具体信息了，客户端需要把服务端报的这个错记录在日志里，方便排查。

回到前言中的场景

服务端并没有报错，而是返回200（调用成功），但是返回的点赞数是个负数（一个明显的错误数据）。套用上边的潜规则就很好处理了，客户端仍然应该做兼容处理，并记录一个log（服务端返回了一个负数），而不是把一个负数直接展示给用户。

测试的重要性

服务端如果报错了，客户端如何兼容，开发肯定会去找产品讨论，因为客户端要处理返回失败的逻辑（else里标红的部分）具体的就是，这个handleServerError方法该如何写

        if (response.isSuccessful) {
            // 成功逻辑：处理正常数据
            val data = response.body()
            updateUI(data)
        } else {
            // 处理服务端返回的明确错误（如 HTTP 404/500）
            handleServerError(response.code(), response.errorBody())
        }

服务端如果没报错，只是收到了明显不合理的数据，客户端有没有做兼容，就需要前言中提到的“收到的点赞数为负数”这条测试用例来兜底了。执行到这条用例的时候，它的预期结果是什么，收到点赞数为负以后客户端应该怎样展示才合适，在设计用例的时候，测试工程师就应该已经和产品经理聊明白了。