如何在 Go 中将 map 数据完整转换为 JSON 数组格式

本文详解如何正确遍历 go 的 map 并序列化为标准 json 数组（而非单个对象），解决因误用赋值导致仅返回最后一项、以及 int 类型 map 键无法直接 json 序列化的常见问题。

如何在 Go 中将 map 数据完整转换为 JSON 数组格式

在 Go 的 Web 开发里，把内存里的 map 数据打包成结构化的 JSON 返回给 API 调用方，几乎是家常便饭。但新手朋友常常会在这里踩两个坑：第一个，是把循环里的赋值当成了追加，结果 API 永远只返回最后一条数据；第二个，是忘了 JSON 规范里白纸黑字的规定——对象的键必须是字符串。这就导致像 `map[int]string` 这种结构，直接交给 `json.Marshal` 会碰一鼻子灰。

不过，咱们今天要解决的问题恰恰绕开了第二个难点。我们的目标不是把整个 map 原封不动地序列化成一个 JSON 对象，而是要把它的键值对，转换成一个结构统一的 JSON 数组。数组里的每个元素都是一个独立的小对象，里面的字段（比如叫 “key” 和 “value”）类型可以自由定义，这样一来，int 类型的键就不再是障碍了。

话不多说，下面就是基于你原有结构（比如用了 httprouter）修正后的完整实现方案：

type UserController struct{}

func NewUserController() *UserController {
    return &UserController{}
}

type Data struct {
    Key   int    `json:"key"`   // 字段名建议小写，符合 Go 惯例；tag 明确指定 JSON 键
    Value string `json:"value"`
}

var datamap = map[int]string{
    101: "apple",
    202: "banana",
    303: "cherry",
}

func (uc UserController) getallkeys(w http.ResponseWriter, r *http.Request, p httprouter.Params) {
    // 正确做法：声明一个空切片，然后用 append 动态扩容
    var result []Data
    for k, v := range datamap {
        result = append(result, Data{Key: k, Value: v})
    }

    // 务必处理 json.Marshal 可能返回的错误（生产环境绝不能忽略）
    jsonData, err := json.Marshal(result)
    if err != nil {
        http.Error(w, "JSON serialization failed", http.StatusInternalServerError)
        return
    }

    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(http.StatusOK)
    w.Write(jsonData) // 更安全：避免使用 fmt.Fprintf 可能带来的额外格式化和转义问题
}

关键修正点说明

来看看具体改了哪里，以及为什么这么改：

• ✅ 切片追加逻辑：原代码中的 `uj = Users{...}` 在每次循环都会创建一个全新的结构并赋值，结果就是把上一次的结果给覆盖了。改用 `result = append(result, ...)` 才是正解，它能确保所有遍历到的键值对都被累积到切片里。
• ✅ 类型声明简化：其实没必要额外定义一个 `type Users []Data`。直接使用 `[]Data` 更加清晰直观，也减少了理解上的歧义。
• ✅ 错误处理：`json.Marshal` 是有可能失败的（比如结构体里包含了不可序列化的字段）。忽略这个错误等于埋下了一个静默崩溃的隐患，所以必须检查 `err`。
• ✅ 响应写入优化：用 `w.Write()` 直接写入字节切片，比 `fmt.Fprintf(w, "%s", result)` 更高效。后者涉及额外的字符串格式化开销，在复杂数据下还可能产生意料之外的转义。

需要留意的几个细节

代码跑通只是第一步，要让它在生产环境里更健壮，还得考虑下面几点：

• 如果前端希望返回的数组是按 key 排序的，记得在遍历 map 之前，先对它的键（keys）进行排序。因为 Go 语言并不保证 map 的遍历顺序。
• 生产环境的 API 通常还需要统一的中间件来处理 CORS、日志记录和 panic 恢复等通用逻辑。
• 示例里的 `datamap` 是全局变量。如果它在并发场景下会被读写，那就必须考虑线程安全问题，可以加上 `sync.RWMutex` 锁，或者评估是否改用 `sync.Map`。

按照上面的方案实现后，最终的 HTTP 响应就会严格符合我们的预期，是一个标准的 JSON 数组：

[
  {"key":101,"value":"apple"},
  {"key":202,"value":"banana"},
  {"key":303,"value":"cherry"}
]