在项目里刚好有3个服务，同一个网关内层的3个服务，两个php的，一个golang的，为了提高负载以及进行分流，部分客户的接口调用会被网关自动分配到go服务。

恰好为了测试，我写了一个全量用户的生产、测试环境调用接口返回结果进行对比的脚本，于是发现了题中的问题：两个php服务里的接口返回值写入xlsx后，直接copy出来是正常的json串，golang的接口返回值copy出来变成双重引号如图

排查过程：

1、先通过python的requests请求接口直接打印出返回值，看看是否是两个双引号，结果发现php跟go服务都是正常的json串。

2、继续排查，猜想问题会不会出现编码传输格式上，于是对比php跟go接口响应标头。

　　php服务响应头如下：

　　

　　go服务应头如下

　　

　　go跟php响应头的差别只在于两点：php多了TimeStamp，Content-Type里面多了charset=utf-8。

　　首先排除TimeStamp，从名称上就可以看出来不会对返回值格式或内容有任何影响；

　　然后尝试用flask编写两个接口，Content-Type里面分别为application/json、application/json; charset=utf-8，写入excel后发现并没有任何不同。

3、响应头也没问题，继续猜想会不会是go服务代码缺陷，接口在return response之前并没有序列化，而是直接返回了object对象？

　　我们先了解一个概念：序列化与反序列化。

　　序列化是把程序对象转换为字节序列的过程，反序列化就是把字节序列恢复为程序对象的过程。

　　因为不同的客户端、服务端可能使用的语言不同，为了兼容都是用序列化之后的数据进行传输，比如前端js将页面参数序列化之后传递给后端java服务。

　　开始实验，本地flask直接返回字典{“username”: username, “password”: password}，写入excel的居然真的出现了两个双引号。

　　

4、于是让开发排查代码里是不是没有作序列化，但是出人意料的是，go代码里是做了序列化才返回的。

　　所以上面的猜想都不成立，研究一度陷入僵局，直到…

5、偶然注意到copy出来的返回值尾巴上有个莫名其妙的换行。

　　

　　根据以前经常写json数据入csv、xlsx文件的经验，就算是格式化后加了多个引号的json数据（例如pandas的to_csv方法里的quoting参数即可控制是否加引号），也不可能加换行符。

　　所以猜想会不会是返回值多了个隐形的换行符，然后在pacharm的cmd里调一下接口看看，果然go服务返回体尾巴上换行了，而php则不会

　　

6、于是在写入excel之前把返回值rstrip()一下做最后的确认，结果从excel复制出来的数据真的没有多重引号了。

至此，揪出来这个go服务的bug！