今天给测试写一个第三方平台的mock服务，在通讯调试中发现一个问题，不管是被测服务本身的日志还是我这边打印的日志，在打印报文 json 时都出现了大量的反斜杠，感觉有点诡异。然后在网上查了下，很快弄明白了。

一般来说一个json序列如果包含较多层的信息，那么我们应该期望这些信息应该是由基本数据类型递归地形成一个个子json对象，并最终汇集成一个最终的json对象。然而在出现多余斜杠的json序列中，一部分json子对象没有以子对象的形式存在，而是以一个 表达json对象的字符串 的形式存在，从内容上来说我们认为它是一个子对象，然而数据上来说它是一个字符串，由于这个字符串表达了一个 json 序列，于是这个字符串中会存在双引号，因此为了在字符串中表达双引号这个字符，它在打印时被携带了前置的转义反斜杠。特别是像我碰到的，这样的情况出现了多层，于是就会出现1个3个7个的反斜杠，看得人脑壳冒烟。回头去看了下我们这头的源码，发现在组包环节 put jsonObj 时大量使用了 toJSONString。Boom。最后由于这是一个已经上线的业务，没法马上改过来，于是只能在 mock 里简单地递归转化一下内容来适配现状。

def jsonObj2str(json_obj):

for key in json_obj.keys():

if type(json_obj[key])== type({}):

json_obj[key] = jsonObj2str(json_obj[key])

return(json.dumps(json_obj,ensure_ascii=False))

事情其实不是特别复杂，但是这里反映出的问题很值得思考。首先，从技术上讲，最基本的数据结构理解不扎实，显然没有弄清楚在 json 操作中 put str 和 put jsonObj 的区别。第二，这个问题严格来说不是一个 error，因为其实只要收发两端在这个问题上达成一致，那么其实这个问题不太会导致数据传输的正确性出问题，但是从程序员的职业角度出发，我认为这个问题反映了当事码农对简洁、优雅、效率这几个程序员必须具备的素养毫无追求，典型的走通就完事的产物。

总结一下就是，出现这样的问题很让人失望，也证明了目前推动落实 review 很有必要。