在Go语言开发中，我们经常需要把数据库查询出来的多行记录转成 []map[string]interface{}，以便在前端接口中灵活输出或做动态处理。这种方式特别适合列不固定、或者不想为每张表写结构体的场景。下面直接看具体实现思路。
为什么要用Map切片
使用结构体接收查询结果是最常见做法，但通过反射绑定到 struct 字段要求提前定义好模型。当后台管理系统的报表模块需要允许用户自定义查询字段时，写死的结构体就不够用了。此时把每一行变成一个 map，键是列名，值是对应数据，整体再放进切片，调用方可以按字符串键随意取值。
另外，一些中间件或配置中心会把数据库内容直接序列化给前端，map 结构天然贴合 JSON 对象，转换成本极低。不过要注意，map 里的值类型通常是 interface{}，后续使用必须做类型判断，否则容易在类型断言时崩溃。
基础实现方式
核心思路是先用 sql.Rows 的 Columns 方法拿到所有列名，然后为每一行构造一个和列数等长的 []interface{} 切片，把每个元素的地址传给 Scan，再逐个把值复制到 map 中。下面是一段完整可运行的示例代码：
package main
import (
"database/sql"
"fmt"
"log"
_ "github.com/go-sql-driver/mysql"
)
func queryToMapSlice(db *sql.DB, query string, args ...interface{}) ([]map[string]interface{}, error) {
rows, err := db.Query(query, args...)
if err != nil {
return nil, err
}
defer rows.Close()
// 获取列名
columns, err := rows.Columns()
if err != nil {
return nil, err
}
columnCount := len(columns)
result := make([]map[string]interface{}, 0)
for rows.Next() {
// 准备接收值的切片
values := make([]interface{}, columnCount)
valuePtrs := make([]interface{}, columnCount)
for i := range values {
valuePtrs[i] = &values[i]
}
if err := rows.Scan(valuePtrs...); err != nil {
return nil, err
}
rowMap := make(map[string]interface{})
for i, col := range columns {
// 数据库驱动常返回 []byte，可转成字符串方便使用
val := values[i]
if b, ok := val.([]byte); ok {
rowMap[col] = string(b)
} else {
rowMap[col] = val
}
}
result = append(result, rowMap)
}
if err := rows.Err(); err != nil {
return nil, err
}
return result, nil
}
func main() {
db, err := sql.Open("mysql", "user:pass@tcp(127.0.0.1:3306)/test")
if err != nil {
log.Fatal(err)
}
defer db.Close()
data, err := queryToMapSlice(db, "SELECT id, name FROM users LIMIT 10")
if err != nil {
log.Fatal(err)
}
fmt.Println(data)
}
上面的代码通过 columns 动态确定字段，避免了硬编码。在 Scan 之后，我们把 []byte 类型的原始数据转成 string，这样生成的 map 在后续 JSON 编码时更友好，不会出现 base64 乱码。
这种写法通用性很强，不论查询多少列都能正确转换。但每次转换都会做反射和循环，数据量极大时会有一定性能损耗，一般业务接口几万行以内完全可以接受。
处理空值与类型问题
数据库里的 NULL 在 Go 的 database/sql 中通常会被扫描为 nil。如果直接把 nil 放进 map 再交给 JSON 编码器，前端拿到的是 null，这是符合预期的。但如果你在代码里对 map 值做断言，比如认为一定是 string，就可能 panic。
更稳妥的做法是提供一个辅助函数，在取值时判断是否为 nil，并给出默认值。例如下面这段代码演示了安全读取字符串和整数的方法：
// 从map中安全读取字符串，空值返回默认值
func getString(m map[string]interface{}, key string, defaultVal string) string {
if v, ok := m[key]; ok && v != nil {
if s, ok := v.(string); ok {
return s
}
}
return defaultVal
}
// 从map中安全读取整数
func getInt(m map[string]interface{}, key string, defaultVal int) int {
if v, ok := m[key]; ok && v != nil {
// 数据库整数可能是int64
if i, ok := v.(int64); ok {
return int(i)
}
if i, ok := v.(int); ok {
return i
}
}
return defaultVal
}
通过这类封装，业务代码不需要到处写啰嗦的判断。同时要注意，不同数据库驱动对时间、小数等类型的表达不一样，有的用 time.Time，有的用 string，统一在转换层处理能减少上层烦恼。
如果你的查询来自用户输入的动态列，记得在 SQL 拼接前白名单校验列名，防止注入。map 转换层只负责把结果搬过来，安全责任仍在拼接逻辑。
与结构体扫描的对比
为了看清两种方案差异，我们可以用一张表来总结：
| 维度 | Map切片 | 结构体扫描 |
|---|---|---|
| 适用场景 | 动态列、报表、中间件 | 固定模型、强类型业务 |
| 类型安全 | 弱，需自行断言 | 强，编译期检查 |
| 开发成本 | 低，不用定义模型 | 高，需维护 struct |
| 性能 | 略低，有反射和装箱 | 较高，直接赋值 |
从表中可以看出，没有绝对优劣，只有合不合适。很多项目会混用：核心交易用结构体，运营后台导出用 map 切片。只要封装好转换函数，代码并不会难维护。
最后提醒，使用 sql.Rows 时一定要 defer rows.Close() 并检查 rows.Err()，否则连接可能泄露。把转换逻辑收口到一个函数里，能让所有调用点都自动获得这些保护。