本文讲解如何将 SQL 查询（如 SELECT * FROM policy）的结果按 policy_name 分组，动态构建多层级 Go 结构体（外层以策略名为键，内层为参数切片），最终序列化为符合前端预期的 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"`
ClassID string `json:"class_id"`
Name string `json:"name"`
// 其他字段...
}关键逻辑在于：用 map[string]Table 按 Name（即策略名）作为键进行分组，而非试图一次性构造 Table 实例。遍历 rows 时，对每行执行三步操作：
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- 扫描到临时
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 组件消费。
