本文详解 go 语言中使用 sql.rows 读取数据库记录时，因误用全局 map 导致 slice 中所有元素指向同一内存地址的常见陷阱，并提供安全、可复用的解决方案。
本文详解 go 语言中使用 sql.rows 读取数据库记录时，因误用全局 map 导致 slice 中所有元素指向同一内存地址的常见陷阱，并提供安全、可复用的解决方案。
在 Go 中，将 SQL 查询结果动态映射为 []map[string]interface{} 是一种灵活的数据处理方式（尤其适用于结构未知或需泛型兼容的场景）。但若未理解 Go 中 map 的引用语义，极易陷入“所有 slice 元素内容相同”的典型错误——正如示例代码所示：尽管循环中多次调用 rows.Next()，最终 mySlice 中每个 map 都显示为最后一行数据。
根本原因在于：Go 中的 map 是引用类型。示例中 myMap 在循环外声明并初始化，每次迭代都复用同一个 map 实例，通过 myMap[colNames[i]] = col 不断覆写其键值；而 mySlice = append(mySlice, myMap) 实际是将同一个 map 的引用（即指针）反复追加进切片。因此，mySlice 中所有元素最终都指向同一块内存，自然全部反映最后一次迭代的值。
✅ 正确做法是：确保每次迭代创建独立的 map 实例。只需将 map 的初始化移入 for rows.Next() 循环内部即可：
// ✅ 正确：每次迭代新建一个 map
for rows.Next() {
err := rows.Scan(colPtrs...)
if err != nil {
log.Fatal(err)
}
// 每次迭代创建新 map，避免引用冲突
rowMap := make(map[string]interface{})
for i, col := range cols {
rowMap[colNames[i]] = col
}
mySlice = append(mySlice, rowMap) // 追加的是新 map 的引用，彼此隔离
// 可选：打印当前行用于调试
fmt.Printf("Row: %+v\n", rowMap)
}⚠️ 额外注意事项：
-
defer rows.Close() 应在 rows 创建后立即调用，且必须在 rows.Next() 循环结束后执行（原代码中 defer 位置不当，可能导致资源未及时释放）。推荐写法：
defer func() { if rows != nil { rows.Close() } }() - *`sql.Null类型需显式处理**：若字段允许 NULL，rows.Scan会填充sql.NullString等类型，直接赋值给interface{}后需在使用前判断.Valid` 字段，否则可能引发 panic。
- 内存效率考量：对海量数据，频繁创建 map 可能增加 GC 压力。如性能敏感，可考虑预分配 mySlice 容量（make([]map[string]interface{}, 0, expectedCount)），或改用结构体切片（[]User）提升类型安全与性能。
- 错误检查不可省略：务必在循环结束后调用 rows.Err() 检查扫描过程是否发生错误（例如类型不匹配），这是 sql.Rows 的惯用模式。
总结而言，解决该问题的核心原则是：让每个逻辑数据单元（即每一行）拥有专属的、生命周期受控的 map 实例。遵循此原则，不仅能规避引用共享陷阱，还能使代码更符合 Go 的内存模型直觉，提升可维护性与健壮性。
