这是笔者长期实践过程中自己归纳总结的一些关于规范的实践要点记录，看自己的笔记已经形成了一篇文章的规模就分享出来，后续有补充会及时更新。

代码里逻辑判断与文案提示分离

{
    "msg":"订单不存在",
    "code":10001,
    "data":{

    }
}

{
    "msg":"商品已下架",
    "code":10002,
    "data":{

    }
}

上方两处返回结果中，code值不同表示不同的含义，做好全局唯一编码，注意不要导致重复，数字的编码可以考虑使用前缀作为不同业务类型的区别，譬如：1xxx表示订单类，2xxx表示商户商品类 等等

另外，对于编码确定后要做好统一的表格文档，便于快速查找和核对，差不多如下：

这样实践的目的很简单，业务方（api接口调用方）可通过code进行业务调度，而msg文案则可以直接显示，甚至可以通过统一的错误文案服务，使用code去换文案。

业务错误、异常bug错误捕获区分

业务错误和程序错误被捕获的异常是不同的，需要做好区分。

异常捕获的错误信息尽量完整，便于追踪排查。

严禁字段透传和无控制字段返回

透传(透明传输)即不做任何字段的更改直接发送给了调用方。

对于从Db或微服务模块读取出的源数据，严禁不经处理就直接传递给了调用方。

例如从MySQL中读取出了如下数组数据：

[
    {
        "id":1,
        "name":"jing",
        "phone":13800138000
    },
    {
        "id":2,
        "name":"yang",
        "phone":13800138001
    }
]

严禁直接就传递给了客户端，而是要经过处理定制后发送给客户端，纵使发送给客户端的字段与读取出来的字段一摸一样也要执行一遍赋值后再返回。

可空字段、对象严格约定好规则

{
    "id":1,
    "config": {
        "is_term":true,
        "time":"2019-08-30 23:23:23"
    }
}

假如上述结构中config字段是可能为空的，为空的表示方法有多种如下：

{
    "id":1,
    "config": {}
}

{
    "id":1,
    "config": []
}

{
    "id":1,
    "config": ""
}

{
    "id":1,
    "config": null
}

{
    "id":1
}

不讨论哪种表示为空的方法最优雅、最牛逼，而是必须确定好一种字段值可空时空值的表示方法，一个项目中不要存在多套规则。

同理null和''、true和1、false和0都要约定好统一的一套规则；而不是各人有各人的写法。

京东微信端：PascalCase、CamelCase、SnakeCase混用，也还有诸如trialproduct这样的奇葩存在，混乱

淘宝pc端：似乎统一做的很好，均是CamelCase