本文解释了 reflect: reflect.Value.Set using unaddressable value 错误的根本原因，阐明 var result *types.Course 与 result := &types.Course{} 的本质区别，并提供符合 Go 惯用法的安全、清晰的查询写法。
本文解释了 `reflect: reflect.value.set using unaddressable value` 错误的根本原因，阐明 `var result *types.course` 与 `result := &types.course{}` 的本质区别，并提供符合 go 惯用法的安全、清晰的查询写法。
在使用 mgo（v2 及早期版本）操作 MongoDB 时，调用 .One() 方法对结构体进行反序列化是常见操作。但若传入一个未初始化的 nil 指针，就会触发 reflect: reflect.Value.Set using unaddressable value 运行时 panic。其根本原因在于：.One() 内部依赖反射对目标地址写入数据，而 nil 指针不指向任何可寻址的内存位置，无法完成赋值。
来看原始代码的问题所在：
var result *types.Course // 声明了一个 *types.Course 类型变量，但值为 nil err := s.collection.Find(...).One(result) // ❌ 向 nil 指针写入 → panic
此时 result 是一个空指针，mgo.One() 尝试通过反射调用 reflect.Value.Set() 将 BSON 数据解码到它所指向的内存，但 nil 没有实际地址，故反射失败。
而改为：
立即学习“go语言免费学习笔记（深入）”；
result := &types.Course{} // ✅ 创建新实例并取其地址，result 指向有效内存
err := s.collection.Find(...).One(result) // 可安全写入或等价写法：
result := new(types.Course) // 同样分配零值内存，返回非 nil 指针
虽然上述修改能避免 panic，但更推荐 Go 社区公认的惯用写法——声明值类型变量，再传其地址：
func (s Store) Lookup(department string, number string) (*types.Course, error) {
var result types.Course // 值类型变量，自动初始化为零值（安全、明确）
err := s.collection.Find(bson.M{
"department": department,
"course_number": number,
}).One(&result) // 显式传递地址，语义清晰，不易出错
if err != nil {
switch err {
case mgo.ErrNotFound:
return nil, ErrNotFound
default:
log.Error(err)
return nil, ErrInternal
}
}
return &result, nil // 按需返回指针
}✅ 优势说明：
- 安全性高：result 总是有效内存，无 nil 指针风险；
- 可读性强：&result 明确表达“将数据写入此处”，符合 Go 的显式地址传递哲学；
- 零值友好：types.Course{} 自动初始化字段，避免未定义行为；
- 内存可控：避免意外逃逸或冗余堆分配（相比 &types.Course{} 在某些场景下更优）。
⚠️ 注意事项：
- mgo 已归档（不再维护），生产环境建议迁移到官方驱动 mongo-go-driver，其 API 更现代、类型更安全（如使用 Decode() 配合非 nil 指针）；
- 若坚持使用 mgo，请确保所有 .One()、.All() 等方法的参数均为已分配内存的非 nil 指针；
- 切勿对未初始化的指针（如 var p *T）直接用于结构体解码，这是典型的反射陷阱。
总结：该错误不是 mgo 的 bug，而是 Go 反射机制对地址合法性的严格校验。理解 nil 指针与有效指针的本质差异，并采用 var x T; f(&x) 这一标准模式，即可彻底规避此类问题，写出健壮、可维护的数据库访问代码。
