位置:首页 > Go > Go中将SQL查询结果映射为多层嵌套结构并输出JSON的方法

Go中将SQL查询结果映射为多层嵌套结构并输出JSON的方法

时间:2026-08-15  |  作者:冻月看渠  |  阅读:0

本文讲解如何将 SQL 查询(如 SELECT * FROM policy)的结果按 policy_name 分组,动态构建多层级 Go 结构体。外层以策略名为键,内层为参数切片,最终序列化为符合前端预期的 JSON 格式。

如何在 Go 中将 SQL 查询结果映射到多层嵌套结构并输出为 JSON

这段内容主要说明一件事:怎样把 SQL 查询结果,比如 SELECT * FROM policy,按 policy_name 进行归类。

在这个基础上,再动态组装出多层级的 Go 结构体。外层用策略名作为键,内层承载参数切片,最后序列化成符合前端预期的 JSON 格式。

在 Go Web 开发里,数据库查出来的数据,往往不能直接交给前端。

通常还需要整理成更适合消费的嵌套 JSON 结构。比如,要把 policy 表里的多条记录,按照 name 字段归并成几个顶层策略对象,再给每个对象挂上各自的参数列表。

这里真正麻烦的地方在于:一次扫描并不能直接把数据塞进嵌套结构里,必须手动完成分组和累积。

结构体定义

首先,定义清晰、可序列化的结构体。

要注意字段名首字母大写以导出,并通过 JSON tag 精确控制键名。

type Table struct { // 建议使用 PascalCase 命名规范,避免保留字冲突
Policy string `json:"policy"`
P[]Parameters `json:"parameters"`
}

type Parameters struct {
PolicyID string `json:"policy_id"`
ClassIDstring `json:"class_id"`
Name string `json:"name"`
// 其他字段...
}

核心处理思路

关键逻辑在于:用 map[string]TableName(即策略名)作为键进行分组。

不要试图一次性构造 Table 实例,而是应该在遍历过程中不断归类和累积。

遍历 rows 时的处理步骤

  • 扫描到临时 Parameters 实例;
  • 检查该 p.Name 对应的 Table 是否已存在,若不存在则初始化空切片;
  • 将当前参数追加至对应策略的 P 切片中。

完整示例代码

// 假设 db.Query 已执行,rows 为 *sql.Rows
defer rows.Close()

// 使用 map[string]Table 实现按 policy name 分组
policyMap := make(map[string]Table)

for rows.Next() {
var p Parameters
if err := rows.Scan(&p.PolicyID, &p.ClassID, &p.Name); err != nil {
log.Printf("scan error: %v", err)
continue // 或返回错误
}

// 若该 policy 名尚未注册,初始化 Table 并存入 map
if _, exists := policyMap[p.Name]; !exists {
policyMap[p.Name] = Table{
Policy: p.Name,
P:make([]Parameters, 0), // 显式初始化切片,避免 nil 引用
}
}

// 追加当前参数到对应策略的参数列表
policyMap[p.Name].P = append(policyMap[p.Name].P, p)
}

// 转换为 JSON 可用的 slice(若需保持插入顺序或返回数组)
var result []Table
for _, t := range policyMap {
result = append(result, t)
}

jsonData, err := json.Marshal(result)
if err != nil {
log.Fatal("JSON marshal failed:", err)
}
// jsonData 即为形如 [{"policy":"A","parameters":[{...}]},{"policy":"B","parameters":[{...}]}] 的字节流

注意事项

  • 结构体字段必须导出(首字母大写),否则 json.Marshal 无法访问;
  • PolicyID/ClassID 等字段名建议采用驼峰命名(Go 习惯),并通过 json:"policy_id" 统一控制 JSON 键;
  • map[string]Table 不保证插入顺序;若前端要求策略按数据库顺序排列,应改用 []Table + 额外逻辑(如先查唯一 policy name 列表再循环查询);
  • 生产环境务必检查 rows.Err()(在 rows.Next() 循环结束后调用),确保无读取错误遗漏;
  • 对于大数据量,可考虑预分配切片容量(如 make([]Parameters, 0, expectedCount))提升性能。

最终结果

最终生成的 JSON 完全匹配需求:每个策略对象包含 "policy" 字符串和 "parameters" 数组。

数组内元素为扁平化的参数对象,结构清晰,语义明确,可直接被前端 React/Vue 组件消费。

免责声明:文中图文均来自网络,如有侵权请联系删除,心愿游戏发布此文仅为传递信息,不代表心愿游戏认同其观点或证实其描述。

相关文章

更多

精选合集

更多

大家都在玩

热门话题

大家都在看

更多