59.0 变 59：JS 社区和 Go 社区的不同反应

现象

最近用 Go 写 API 接口，前端传了一个 JSON：

{ "price": 59.0 }

后端接收后原样返回，前端收到的却是：

{ "price": 59 }

小数点后面的 .0 消失了。

这不是 Bug，是 JSON 规范的一部分。在 JSON 标准中，59 和 59.0 是完全等价的数字，序列化时自动省略多余的 .0 是正常行为。

有意思的地方

我去网上搜了一圈这个现象，发现一个有趣的区别。

JavaScript 社区的讨论：

"为什么 JSON.stringify 会把 59.0 变成 59？"
"怎么保留小数点后面的 0？"
"这是不是 JSON.stringify 的 Bug？"

讨论方向是：质疑这个行为，试图改变它。

Go 社区的讨论：

"前端显示价格怎么保留两位小数？"
"GORM 的 float64 怎么自定义 JSON 序列化？"
"返回给前端的价格格式怎么处理？"

讨论方向是：接受这个行为，直接找解决方案。

同样一个现象，两个社区的关注点完全不同。

为什么会有这种差异？

1. 语言的设计目标不同

JavaScript 诞生于浏览器环境，设计目标是"灵活、易用、让事情能跑起来"。开发者习惯了对语言和框架的各种行为进行配置、调整、打补丁。

遇到任何"不符合预期"的行为，第一反应往往是："这个能不能配置？有没有 npm 包能解决？"

Go 诞生于系统编程环境，设计目标是"明确、可靠、可维护"。标准库的行为通常就是最终行为，能配置的地方很少。

遇到类似问题，第一反应是："这就是这样设计的，那我的业务怎么处理？"

2. 类型系统与"数据 vs 表现"的认知差异

在 Go 里，float64 明确是一个浮点数类型。一个浮点数的值就是 59，在计算机内存里本来就没有 .0 这个概念。.0 是显示格式问题，不是数据本身。Go 开发者天然习惯了数据归数据，格式归格式。

在 JavaScript 里，虽然 59.0 和 59 在底层都是 Number（双精度浮点数），但因为 JS 深度绑定浏览器 UI，前端开发者在写下 59.0 时，潜意识里往往是在处理一个"UI 展示效果"，而不是一个"浮点数"。当 JSON.stringify 抹去 .0 时，他们会感到焦虑："我写的界面格式被破坏了。"

这里有一个更深层的认知差异：

JSON 本质上是数据交换格式，而非表现层格式。JS 社区的某些讨论，本质上是试图让 JSON 承担表现层的职责（带上格式信息）；而 Go 社区的反应，则高度契合了 JSON 的设计初衷——只传递纯粹的数据，表现交给客户端。

3. 社区文化与解题思路的碰撞

这种认知差异和语言基因，直接导向了两种不同的工程实践和社区生态。

JS/Java 社区的"配置思维"： 试图在序列化阶段"把格式保下来"。生态里有大量关于 JSON 序列化的讨论，习惯了寻找诸如 json-bigint 或魔改 replacer 的配置项，寄希望于框架层面解决展示问题。

Go 社区的"工程思维"： 标准库的 encoding/json 功能有限，社区也习惯了"标准库给什么就用什么"的节奏。既然标准库的行为是确定的，那就在业务层面解决，通常有两种直白的路数：

方案 A（前后端分离原则）：明确"格式是前端的事"。后端只传纯数字 59，前端在客户端用 .toFixed(2) 自行渲染成 ¥59.00。
方案 B（后端强控格式）：把字段类型改为 string，或者通过实现自定义的 MarshalJSON 接口，强行将数字格式化为字符串（如 "59.00"）丢给前端：

type Price float64

func (p Price) MarshalJSON() ([]byte, error) {
    return []byte(fmt.Sprintf(`"%.2f"`, p)), nil
}

这不是谁好谁坏

JS 社区的"质疑和配置"让生态变得丰富灵活，前端开发效率极高。

Go 社区的"接受和解决"让代码变得稳定可控，后端服务可靠耐用。

两种不同的思维，对应了两种不同的使用场景，也培养出了两种不同的开发习惯。

最后

如果你是从 Node.js 转到 Go 的开发者，遇到这种情况不需要困惑。同样的问题，换个语言，讨论方式就是不一样。

不是谁做对了，谁做错了。是两种语言的基因不同。