或许你应该知道...

也许您会感到困惑，上文已经提到客户端原生请求的种种便利，为什么这里useNativeHttp的参数默认是关闭呢？实际上，在我们设计http模块的初衷确实是默认开启原生请求的，但很快我们发现原生请求存在更多的限制，如果您在现有的业务中通过kreator的http模块进行改造重构，很可能您会遇到一些之前没有出现过的问题。

例如在接口响应的参数类型不规范时，iOS端会直接闪退（由于GaCommon解析JSONString失败）。类似这样的情况会让业务开发者十分困惑，他们可能会耗费大量的时间来排查此类问题。

我们会尽量将这类问题列出帮助您回避陷阱，但我们还是建议——只在您认为需要使用原生请求与请求加密的情况下再使用它（例如涉及资产、支付、个人隐私信息的需求场景）。

标准化的返回值

源自各种历史原因、团队原因、人的原因等等，不是每一个网关——或者同一个网关下，接口的返回值结构都不见得是完全一致的。

理论上，客户端只处理这样的格式：

{
  "code": "0000",
  "data": {
    "a": "1"
  },
  "msg": "success"
}

此时http模块处理为success回调与Promise.resolve执行，意为请求成功。
code不为0000的时候则认为请求失败，进入fail回调与Promise.reject处理。
除此以外的任何情况都将返回code为9999，msg值为"网络错误"。

绝大多数系统，包括App、小程序与Web均以此为规范处理。但是有时候可能会出现特例情况，这可能是上古时期的接口或者后端团队没有按照规范开发导致的。

因此Kreator对常见的异常数据结构亦做了兼容处理，以下几种数据结构也是可以被处理的：

{
  "code": "0007",
  "result": "好像出错了",
  "msg": "success"
}

{
  "code": "0007",
  "data": "好像出错了",
  "msg": "success"
}

{
  "result": {
    "msg": "领取次数达到上限！",
    "code": "0001",
    "data": "会员系统返回:领取次数达到上限！"
  }
}

如果以上情况仍然不能满足你的情况，请强推与你合作的后端研发人员修改出参结构，Kreator不会对这种异于规范的情况做任何兼容处理。

异常返回的处理

对于多数开发者来说，customRes的用途显得相当意义不明，并且让前后端的交互规范变得模糊。
实际上，它的作用在于"适配不合常规数据结构规范的接口返回值"。

举例来说，通常情况下后端会返回如下格式的数据：

const res = {
  code: '0000',
  data: {xxxx},
  result: 'success'
}

这种是非常正常的，但如果返回这样的数据：

const evilRes = {
  result: JSON.stringify({
    code: '0000',
    data: {xxxx}
  })
}

这会导致kreator认为返回了一个非法的数据结构，从而直接抛出9999的网络异常信息。
原则上说，这样的数据结构是完全不合规范，需要后端开发者修改的。但是这可能是一个相当古老的系统——并且它依旧在生产环境运行着，修改返回值或许有十分难以预料的风险。
此时前端开发者也可以选择使用customRes参数来绕过kreator的规范检测，自行处理数据结构。

同时我们希望开发者永远不会遇到这种尴尬的情况。