本文详解 Go 中因循环变量地址复用导致 Scan 时多个指针指向同一内存地址的问题，并提供安全、可复用的解决方案，确保数据库字段能准确映射到结构体各字段。
本文详解 go 中因循环变量地址复用导致 `scan` 时多个指针指向同一内存地址的问题，并提供安全、可复用的解决方案，确保数据库字段能准确映射到结构体各字段。
在使用 sql.Rows.Scan() 或 sql.Row.Scan() 批量扫描数据库查询结果时，常需构造一个 []interface{}，其中每个元素为对应字段的地址（即 *string、*int64 等）。常见误区是直接对循环变量取地址，例如：
for i, val := range userLoginKeys {
keys[i] = &val // ❌ 错误！val 是每次迭代复用的局部变量
}
这段代码中，val 是 for range 循环的单一副本变量，其内存地址在整个循环中不变。因此 &val 每次都返回同一个地址（如输出中的 0xc4201ca2c0），导致 keys[0] 和 keys[1] 实际指向同一块内存。后续 row.Scan(keys...) 会将两个字段值依次写入该地址，最终二者内容完全相同——这正是你观察到密码被覆盖用户名、或两者值一致的根本原因。
✅ 正确做法是：取源切片中对应索引元素的地址，而非循环变量的地址：
userLoginKeys := structs.Names(UserLogin{}) // 返回 []string{"Username", "Password"}
keys := make([]interface{}, len(userLoginKeys))
// ✅ 正确：取 userLoginKeys[i] 的地址（每个字符串独立存储）
for i := range userLoginKeys {
keys[i] = &userLoginKeys[i]
}
但注意：structs.Names() 返回的是字段名（string 类型），而 Scan 需要的是目标结构体字段的地址，不是字段名的地址！上述修正虽解决了地址复用问题，却仍无法达成原始目标——将查询结果存入 UserLogin 实例的 Username 和 Password 字段中。
? 真正推荐的实践方案（结构体自动绑定）：
应避免手动管理字段名与指针数组，改用更安全、语义清晰的方式：
func Login() {
row := sql.QueryRow("SELECT username, password FROM users WHERE username = ?", "golang")
var user UserLogin
err := row.Scan(&user.Username, &user.Password) // ✅ 直接传结构体字段地址
if err != nil {
log.Fatal(err)
}
fmt.Printf("Logged in: %+v\n", user)
}
若需完全动态（如字段数/类型未知），可结合反射构建字段地址切片：
func scanIntoStruct(row *sql.Row, dst interface{}) error {
v := reflect.ValueOf(dst).Elem() // dst 必须是 *T
if v.Kind() != reflect.Struct {
return fmt.Errorf("dst must be address of struct")
}
fields := make([]interface{}, v.NumField())
for i := 0; i <p>⚠️ <strong>关键注意事项：</strong> </p>
-
for range中的循环变量是值拷贝，&val总是同一地址；务必使用&slice[i]或反射Field(i).Addr()获取独立地址； -
structs.Names()仅返回字段名字符串，不能替代字段地址，不可用于Scan； - 生产环境优先使用显式字段扫描（
&u.Username, &u.Password），清晰、高效、零反射开销； - 若必须动态扫描，请确保目标结构体字段可寻址（即传
&structVar而非structVar）。
通过理解 Go 的变量生命周期与地址语义，即可彻底规避此类“指针幻影”陷阱，写出健壮可靠的数据库映射逻辑。
