如何自定义 Go 结构体字段的默认序列化命名规则（JSON/BSON）

如何自定义 Go 结构体字段的默认序列化命名规则（JSON/BSON）

Go 语言中 struct 字段的 JSON 和 BSON 序列化默认采用 PascalCase 到 snake_case 或原名直传，但无法全局修改默认行为；需通过结构体标签显式声明，或借助代码生成工具实现“零标签”优雅命名。

在 Go 语言里处理结构体序列化时，很多开发者会遇到一个共同的困惑：为什么字段名没有按照预想的方式自动转换？比如，你希望 JdId 在 JSON 里变成 "jdId"，但结果却可能是 "JdId" 或者 "jdid"。这背后其实涉及 Go 语言一个非常明确的设计哲学。

先说核心结论：Go 语言中 JSON 和 BSON 标签的默认行为是不可更改的。无论是标准库的 encoding/json，还是 MongoDB 官方驱动 go.mongodb.org/mongo-driver/bson，它们内部都硬编码了字段名的映射逻辑，没有留下可以全局修改的“后门”。

• 对于 json 包，默认行为就是直接使用导出字段的名字（例如 JdId 会变成 "JdId"），它不会自动帮你转换为 camelCase。
• 对于 bson 包，默认行为则是转换为小写蛇形命名（JdId 会变成 "jdid"），同样不支持内置的 camelCase 转换。

所以，如果你观察到 JdId 最终序列化成了 "jdId"，这并非 Go 运行时做了什么“智能”的默认动作，而恰恰是你手动添加了结构体标签后显式指定的结果。这一点必须明确：Go 本身不存在像 Rust 的 serde 属性或 Python 的 pydantic 那样可配置的全局命名策略钩子。

✅ 正确做法：显式声明标签

既然全局配置行不通，那最直接、最推荐的做法就是为每个需要自定义命名的字段显式加上标签。这虽然看起来有点繁琐，但却是最清晰、最可靠的契约。

type CvJdRelationInfo struct {
    JdId            string `json:"jdId" bson:"jdId"`
    CvId            string `json:"cvId" bson:"cvId"`
    Status          int16  `json:"status" bson:"status"`
    AcceptTimestamp int64  `json:"acceptTimestamp" bson:"acceptTimestamp"`
}

这里有个细节值得注意：在 bson 标签里，像 "acceptTimestamp" 这样包含大写字母的 camelCase 字段名是完全合法的，MongoDB 驱动能够很好地支持，不必强制转换成下划线格式。

⚠️ 常见误区与注意事项

在实际编码中，有几个坑需要小心避开：

• ❌ 不要省略引号：标签值必须用双引号包裹。写成 `json:jdId` 是语法错误，正确的形式是 `json:"jdId"`。
• ❌ 理解特殊标记的用法：json:"-" 表示完全忽略该字段，而 json:",omitempty" 表示当字段为零值时省略。这两个标记的格式是固定的，不能混用或省略引号。
• ✅ 动态映射的替代方案：对于配置解析等需要运行时动态映射的场景，可以考虑使用 mapstructure 库（如 github.com/mitchellh/mapstructure）。不过要记住，这只是补充方案，并不能替代序列化标签在 API 契约中的核心作用。
• ?️ 追求“零标签”的工程化方案：如果项目规模很大，觉得手动添加标签太麻烦，有没有更优雅的办法？答案是肯定的。你可以结合 go:generate 指令和自定义的代码生成器（例如基于 golang.org/x/tools/go/packages 分析代码的抽象语法树），自动为结构体生成一个带有标准 camelCase 标签的副本。这已经成为中大型 Go 工程中规模化解决命名一致性问题的主流方案。

总结

归根结底，Go 语言的设计哲学强调显式优于隐式。结构体标签就是一份清晰的序列化契约。与其花费精力去寻找一个可能并不存在的全局配置开关，不如将规范化的命名策略固化为团队开发约定。然后，通过 CI/CD 流程中的静态检查工具（比如 revive 的定制规则），或者前面提到的代码生成工具，来强制保障这种一致性。

这样做，不仅完全符合 Go 语言的惯用法，避免了运行时的不确定性，也让代码的意图对每一位阅读者都清晰可见。毕竟，明确的约定，总是比隐晦的魔法更值得信赖。