可能是另一场圣战：后端返回的 JSON 的值是只要 String 类型呢，还是各种类型都包括呢？

[winiex]

工作中和不同的客户端开发者合作过，有的要求返回的 JSON 统一只包含 String 类型：

{ a: "THYM", b: "107", c: "false" }

而有的则要求数据要表达自己的类型：

{ a: "THYM", b: 107, c: false }

我个人是支持第二种写法的，因为不用再写一堆转 String 和转回类型的代码。大家团队都选择何种方式呢？又是出于何种原因与理由呢？

[southsala]

Json 也是有标准的好吧。。。 第一种这个不算 Json 了吧，算变种

[learnshare]

第一种是不行的，绝对不行

[incompatible]

@luoyou1014 具体原因是“客户端数据类型错误的时候会导致应用直接闪退”，那就解决这个原因啊。你们客户端工程师连异常处理都不懂的？

[Zzdex]

这还站什么？返回第一个直接打死

[VeryCB]

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Number/MAX_SAFE_INTEGER

JS 有最大安全整数的限制，所以当有使用大整数的场景下用 string 来表示。不过这需要开发者提前了解需求中是否会出现超过最大安全整数的场景，需求是否合理以及是否可以规避。一般来说用到的可能性很小。

其他的用第一种的理由应该都是偷懒吧，甚至可能更麻烦一些。

[loveyu]

就是客户端偷懒，问过了，说实现复杂

[applehater]

有种叫 BSON

[zhujinliang]

第一种，一个 if (obj.c) { ... } 就等着出诡异的 bug 吧

[dacapoday]

和楼主有同样的疑惑（还有 bool 用 0,1 表示），经常出现在 java 程序员里，应该不是不理解(甚至不知道？)JSON 规范。
只用 string 便于存储到数据库里，建表和编写简单。

[HangoX]

@luoyou1014 别傻了，客户端从开发开始都是信不过服务器的，所有解析的地方都是对 错误做了 catch 处理，绝对不会崩溃的。

[scriptB0y]

提出第一种要求的是银行吧，我还见过客户端将服务器 SSL 证书验证写死在代码里，导致人家服务方不方便更换 SSL 证书的。

[kslr]

直接 true 会有问题 中间层都是做了转换的 0 or 1

[ikaros]

第一种让别人怎么解？

[boywang004]

万事不能一棍子打死！我仔细想了下都是 string 的方案……真 tm sb ……

[janxin]

第一种方案很简单的思路，假如你在一个管控非常差的团队，又要求产品很稳定，但是哪个产品和领导每天想着要更新迭代加功能。程序员质量又没有那么好，甚至有些文档都没有。一些时候你调用别人的接口数据直接返回了也没处理。某天，有个傻逼，没注意数据类型把类型改了，你发现你的接口客户都不能用了…

[Eoss]

@huclengyue

那些使用第一种，bool 使用 0，1 表示的，怎么让前端判断 false，true ？
Boolean(Number('0')) ???

[zythum]

第一种并不是完全不对的，其实避免了一些问题。

比如，有些语言是强类型，有些事弱类型，有些 Number 有 Int,BigInt, Float 的区别有些没有。所以传数字有时候是有歧义的。这是不用语言间天然的，比如 js, 数字大于 32 为带符号整型就傻逼了，但是 JSON 官方貌似并没有规范这个。

所以第一种并不一定是 SB，拍脑袋定的，只是他们或许是被坑过的同学。

[ZiLong]

@imn1 对于你提到的预处理不甚理解?就是浮点数精度问题和大整数问题?是否可以这样制定规则,浮点数和大整数需要用 string 类型,其他仍然用原类型就不出出问题了?如果要出问题,可以举个例子么

[momocraft]

在第一种人写的系统中使用字符串 "null" 可能会导致一些有趣的问题

[chinvo]

@zythum #37 无脑用 string 也不对，比如 boolean, null