当 Go 方法被调用时，若其指针接收器为 nil 且方法内直接访问其字段（如 m.hash），将触发「invalid memory address or nil pointer dereference」panic；这是常见但易被忽略的空指针错误。
当 go 方法被调用时，若其指针接收器为 nil 且方法内直接访问其字段（如 `m.hash`），将触发「invalid memory address or nil pointer dereference」panic；这是常见但易被忽略的空指针错误。
在 Go 中，方法可以合法地被 nil 指针调用——语言本身不禁止，是否安全完全取决于方法内部实现。正如示例中 (*Channel).Attributes() 所示，第 36 行 redisHash := "sd:channels:" + m.hash 直接解引用 m 获取 hash 字段，而此时 m == nil，即 nil.hash 触发运行时 panic。
这并非 Go 编译器或 Redis 库的问题，而是调用方传入了未初始化的 *Channel（例如 var c *Channel; c.Attributes()），而方法未做防御性检查。
✅ 正确做法：在方法入口显式校验接收器是否为 nil：
func (m *Channel) Attributes() (*ChannelAttrs, error) {
if m == nil {
return nil, fmt.Errorf("Channel.Attributes called on nil *Channel")
}
redisHash := "sd:channels:" + m.hash
rc := m.ctx.RedisPool.Get()
defer rc.Close() // 推荐用 defer 替代手动 Close，避免遗漏
values, err := redis.Values(rc.Do("HGETALL", redisHash))
if err != nil {
return nil, err
}
attrs := ChannelAttrs{}
if err := redis.ScanStruct(values, &attrs); err != nil {
return nil, err
}
return &attrs, nil
}
⚠️ 注意事项：
-
defer rc.Close()更健壮（即使后续 panic 也能确保资源释放）； -
redis.ScanStruct可能返回错误，应显式检查； - 若业务逻辑允许
nil接收器（如String()方法返回"nil"），需主动处理；否则一律建议早期 fail-fast； - 在构造函数（如
NewChannel()）中确保返回非-nil 指针，或使用静态检查工具（如staticcheck）捕获潜在 nil 调用。
总结：Go 的 nil 接收器不是 bug，而是特性；关键在于开发者需明确每个方法的契约——是否接受 nil，并在文档和实现中保持一致。预防此类 panic 的最佳实践是：所有解引用前加 nil 检查，尤其在公共方法入口处。
