服务端开发错了，客户端就应该错着适配

前情提要

我们的产品今日在开发环境暴露出一个风险，某些数据取值取不到了导致产品崩溃。

排查了半天数据和逻辑之后，发现是因为某个接口返回的数据新加了一种类型，但是这种类型的定义和之前的另一种类型是相同的，导致代码合并后，有的数据处理认为是之前的类型，有的认为是之后的类型，导致某些判断分支没有达成，最后导致数据没有正确解析。

问题简述

我们排查了问题之后，理了一下现在的逻辑。

假设我们之前的数据有 A ，B ，C 三种类型，然后根据数据的 type 字段等于 A ，B ，C 来判断数据类型，再根据类型去做相应的数据解析和操作。

但是现在服务端只在某些接口中，把 C 类型给区分成了 C 类型和 D 类型。C 类型的 type 字段是 C ，D 类型的 type 字段是 D 。但是现在的 D 类型的数值是我们之前客户端用的 C 类型，现在的 C 类型则是之前我们客户端会过滤掉的一种数据。老的接口中依旧只有 type 值为 C 。

于是我们现在如果需要在老的接口判断是否是我们需要的类型，就要经历下面几个判断才能确定值的类型。

这个数据来自新接口还是老接口
如果是老接口，那他的 type 是否等于 C
如果 type 等于 C ，他是否具有 data 字段
如果具有 data 字段，他的 data 字段下是否具有 sub_type 字段
如果具有 sub_type 字段，sub_type 字段是否等于 1
如果等于 1 ，那他就是我们之前用的老的 C 类型
如果等于 2 ，那他就是我们之前要过滤掉的类型

争议

理清逻辑后，我就去找服务端理论，为什么要设计成这样。

讨论了半天，总之就是服务端那边不同的人代码逻辑没有统一，最后导致类型定义不统一。

但是服务端表示我们不会改，因为改了容易出问题，而且 Web 端已经适配了，希望我们也适配一下。

我便问他: “但是你这逻辑已经错了，不处理一下吗？我们要适配你们的错误逻辑吗？”

服务端表示: “服务端写错了你们就错着适配吧。”

cowcomic

12 小时 46 分钟前

是谁的问题和这个问题谁改是两件事情

是谁的问题是个定性判断，就你说的这个情况，肯定是后端的问题，已经上线接口的定义怎么能轻易修改，这部分向上反馈要的是公道和后续的处理整改

至于这个问题谁改这个事儿，道理上也应该是后台改，但实际上是成本的考量，谁改成本最低，这个成本包括但不限于（开发成本，测试成本，投入的时间造成的机会成本，团队教育的成本，等等）不同的人看到的不一样，这块就让你们领导去 PK 吧

lyxxxh2

12 小时 41 分钟前

"而且 Web 端已经适配了"
那得先将 web 改了,得考虑下时间成本,让有老大决定吧。

不过话说回来:
我认为产品崩溃不是类型问题,是沟通上的。
1. 这种特殊情况,api 文档不标个备注?

2. "如果是老接口，那他的 type 是否等于 C... " 逻辑就太冗余了,没那么复杂啊。
拦截处理就行。
例如 js:
```
r1 = Promise.resolve({c:1}) # 老接口重写类型
.then(v => {v.c = 'b'; return v}).then(v => console.log(v.c))

r2 = ... # 新接口不管
```