为何JSON反序列化后再序列化字节数不同但结果一致？

这是个非常常见的JSON处理问题，我来给你拆解背后的几个核心原因：

1. 格式化空白字符的差异 #

原始GeoJSON文件通常会包含缩进、换行、空格这些用于提升可读性的格式化字符，而Go标准库的json.Marshal默认生成的是紧凑无格式的JSON字符串——它会去掉所有不必要的空白字符，比如键值对之间的空格、换行符、缩进空格。

举个例子：
原始文件内容（带格式）：

{
  "type": "Point",
  "coordinates": [100.0, 0.0]
}

json.Marshal生成的结果（紧凑格式）：

{"type":"Point","coordinates":[100,0]}

两者的字节数自然不同，但数据逻辑完全一致。如果想要让序列化后的结果和原始格式更接近，可以使用json.MarshalIndent来生成带缩进的JSON，这时候字节数会更贴近原始文件。

2. 数值表示的简化 #

GeoJSON中的浮点数（比如坐标值100.0）在反序列化为Go的float64类型后，再次序列化时会被简化为更紧凑的形式——比如.0会被省略，直接输出100。这种简化在JSON语法中是完全合法的，数值的逻辑值没有任何变化，但会减少字节数。

3. 字段顺序的变化 #

Go的json包在序列化结构体时，是按照结构体字段的声明顺序来排列JSON键值对的；而原始GeoJSON文件的字段顺序可能和你的结构体声明顺序不一致。

虽然JSON本身是无序的键值对集合（字段顺序不影响数据逻辑），但字段顺序的变化会导致生成的字节数组内容不同，字节数也可能随之变化（比如不同字段名的长度差异，顺序调整后总字节数会有波动）。

总结 #

这些都是JSON序列化/反序列化过程中的正常现象，JSON的语法允许这些格式上的差异，只要核心数据结构和值等价，就不会影响业务逻辑。如果确实需要让序列化后的字节数组和原始文件完全一致，你需要额外处理格式化规则、数值表示方式、字段顺序这些细节，但大多数场景下完全没必要——因为JSON的逻辑等价性不依赖于这些格式细节。

内容的提问来源于stack exchange，提问作者Mzia