<p>直接用 sql.Rows 扫描到 map[string]interface{} 再序列化是最轻量可控的方式；因预定义 struct 要求字段名、数量、顺序在编译期固定，而动态 SQL（如 SELECT * JOIN GROUP BY 或带别名/聚合的查询）返回列结构不可预知，易导致 Scan panic 或数据错位，故必须用 rows.Columns() + []interface{} 动态构建 map。</p>
直接用 sql.Rows 扫描到 map[string]interface{} 再序列化，是最轻量、最可控的方式；别碰 database/sql 自带的反射式扫描（比如扫到 struct），它对动态字段完全无能为力。
为什么不能用 Scan 到预定义 struct
struct 要求字段名和数量在编译期固定，而复杂 SQL（如 SELECT * FROM ... JOIN ... GROUP BY ... 或带条件聚合的查询）返回的列名、类型、数量都可能动态变化。一旦列名不匹配或顺序错位，Scan 会直接 panic：sql: expected 3 destination arguments in Scan, not 4 或 sql: Scan error on column index 1: unsupported driver.Value type struct { ... }。
常见场景包括：报表类接口、后台通用导出、SQL 构建器生成的动态查询、多租户 Schema 下的元数据驱动查询。
- 字段名来自
AS别名或数据库函数（如COUNT(*) AS total），无法提前写 struct 字段 - 同一接口可能执行不同 SQL（如按日期聚合 vs 按地区聚合），返回结构不一致
- 某些列类型是
NULL可能对应*string/*int64，但 struct 字段类型必须一一对应，否则 Scan 失败
正确做法：用 rows.Columns() + rows.Scan() 动态构建 map
核心逻辑是先读取列名，再逐行用 []interface{} 接收所有值，最后映射成 map[string]interface{}。关键点在于：所有值必须用 interface{} 接收，由 database/sql 驱动自动转换为 Go 原生类型（string、int64、float64、bool、nil 等）。
立即学习“go语言免费学习笔记（深入）”；
// 示例：动态读取任意查询结果
cols, err := rows.Columns()
if err != nil {
return nil, err
}
defer rows.Close()
<p>var result []map[string]interface{}
values := make([]interface{}, len(cols))
valuePtrs := make([]interface{}, len(cols))
for rows.Next() {
for i := range columns {
valuePtrs[i] = &values[i]
}
if err := rows.Scan(valuePtrs...); err != nil {
return nil, err
}
row := make(map[string]interface{})
for i, col := range cols {
// 处理 nil：driver.NullXXX 会被自动转为 nil，但某些驱动（如 pq）可能返回 *string 等
v := values[i]
if v == nil {
row[col] = nil
} else if b, ok := v.([]byte); ok {
// []byte 是 text/varchar 的默认载体，转 string 避免 JSON 序列化为 base64
row[col] = string(b)
} else {
row[col] = v
}
}
result = append(result, row)
}
return json.Marshal(result)
-
rows.Columns()返回的是[]string，不是sql.ColumnType—— 后者需要额外调用ColumnTypes()，且各驱动支持程度不一，动态场景下没必要 - 必须用
[]interface{}+&values[i]方式传参，不能直接传values，否则Scan会报cannot use values (type []interface {}) as type []interface {} in argument to rows.Scan - 注意
[]byte类型：PostgreSQL 驱动（pq）和 MySQL 驱动（mysql）默认把字符串返回为[]byte，不转string会导致 JSON 输出为 base64 编码
性能与边界情况处理
大结果集（>10k 行）下，反复 make(map[string]interface{}) 和 append 会触发 GC 压力；同时，json.Marshal 对 nil、[]byte、time.Time 等类型默认行为未必符合预期。
- 避免内存浪费：预先
result := make([]map[string]interface{}, 0, estimatedRows)，如果能预估行数（如加SELECT COUNT(*)） -
time.Time默认被json.Marshal格式化为 RFC3339 字符串（含时区），若需 UTC 或自定义格式，得提前转成string或用自定义 marshaler - JSON 不支持
NaN、+Inf、-Inf，如果数据库字段可能是 float 且含非数字值，json.Marshal会直接 panic，需提前过滤或替换 - 某些驱动（如 sqlite3）对
NULL的处理不一致：有的返回nil，有的返回sql.NullString实例，建议统一用v == nil || (rv := reflect.ValueOf(v); rv.Kind() == reflect.Ptr && rv.IsNil())判空
真正麻烦的不是组装 JSON，而是列类型推断和 NULL 处理——不同驱动、不同数据库对同一 SQL 的返回类型可能不同，靠代码硬编码适配不如在 SQL 层用 COALESCE(col, '') 或 CAST(col AS TEXT) 统一类型。动态组装的本质，是把类型协商从 Go 层移到 SQL 层。
