Go 的 json.Marshal 默认不保证字段顺序，struct 导出字段按声明顺序输出，但 map 无序；需保序时优先用 struct，动态场景可用 []*json.RawMessage + slice 手动构造。
Go 的 json.Marshal 默认不保证字段顺序，这是语言规范决定的
go 中 struct 字段在序列化为 json 时，json.marshal 按字段声明顺序输出——但仅限于导出字段（首字母大写），且一旦用 map[string]interface{} 或 map[string]any，顺序就完全丢失，因为 go 的 map 是无序的。这不是 bug，是设计使然。
常见错误现象：json.Marshal 输出字段顺序和 struct 定义不一致（实际极少发生），或更典型的是：用 map 构造数据后，每次运行 JSON 字段顺序都随机，导致测试不稳定、diff 难读、API 文档示例不可复现。
- 若必须保持顺序，优先用
struct+ 显式字段声明，避免动态map - 若需动态键名（如配置拼接、响应字段按条件增删），改用
map[string]any的替代方案：map[string]*json.RawMessage或第三方库如github.com/iancoleman/orderedmap - 注意：即使 struct 字段顺序固定，加了
json:"-"或json:"name,omitempty"不影响剩余字段的相对顺序
用 json.MarshalIndent 格式化输出，但不改变字段顺序逻辑
json.MarshalIndent 只控制缩进与换行，对字段顺序毫无影响。它只是把原本一行的 JSON 拆成多行并缩进，可读性提升，但底层仍是调用 json.Marshal 的同一套序列化逻辑。
使用场景：调试日志、CLI 工具输出、生成可读配置文件。
- 参数：第一个是待序列化值，第二个是 prefix（通常空字符串），第三个是 indent（如
" "） - 性能影响：比
Marshal略慢，因需额外字符串拼接，但对调试/非高频路径无感 - 示例：
data := struct{ Name string; Age int }{"Alice", 30} b, _ := json.MarshalIndent(data, "", " ") // 输出： // { // "Name": "Alice", // "Age": 30 // }
想严格保序又需动态字段？用 map[string]*json.RawMessage 手动控制
这是标准库内最轻量、无依赖的保序方案：把每个字段的 JSON 片段预先序列化为 *json.RawMessage，再按需插入到有序 map（实际用 slice 模拟 map 行为）中。
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
关键点在于：你掌控序列化时机和插入顺序，RawMessage 跳过二次编码，保留原始字节流顺序。
- 不能直接用
map[string]*json.RawMessage—— map 本身无序，必须用[]struct{Key string; Val *json.RawMessage}存储 - 每个字段先
json.Marshal成[]byte，再转为*json.RawMessage - 最后遍历 slice 构造 JSON 对象字节流，可用
bytes.Buffer拼接{、"key": value、} - 缺点：代码略啰嗦，不适合超简单场景；优点：零外部依赖，完全可控
第三方库如 orderedjson 或 go-toml 的类 JSON 库不是通用解
别被名字误导：github.com/segmentio/orderedjson 实际是为解析保留顺序而生，其 Marshal 仍基于 map，不解决输出顺序问题；go-toml 是 TOML 库，和 JSON 无关。
真正可用的极简方案只有两个：
- 坚持用
struct—— 最省心，适合 API 响应结构固定场景 - 手动构造有序字节流（
RawMessage+ slice）—— 适合字段名动态生成但顺序敏感的场景，比如 OpenAPI spec 生成、审计日志字段排序
最容易被忽略的一点：哪怕用了所有保序手段，如果上游数据源（如数据库查询、HTTP header 解析）本身顺序不确定，最终 JSON 顺序还是可能漂移——保序得从输入源头开始控制。
