*io.Reader 几乎总是错的，因为接口本身是引用类型，*io.Reader 不仅冗余，还易致 panic；正确做法是直接使用 io.Reader，仅在需修改接口内状态时用指针接收器实现，而非暴露 *interface{}。
为什么 *io.Reader 几乎总是错的
Go 中接口本身已是引用类型，*interface{} 或 *io.Reader 不仅多余，还常导致运行时 panic。典型错误是把一个具体类型地址直接转成 *io.Reader，比如：var r *io.Reader = &os.File{} —— 这会编译失败，因为 &os.File{} 类型是 *os.File，不满足 *io.Reader（后者要求指针指向的是接口值，不是实现类型）。
真正能赋值给 *io.Reader 的，只有指向接口变量的指针，例如：
var r io.Reader = os.Stdin<br>var pr *io.Reader = &r // 合法：&r 是 *io.Reader
但这种写法极少有实际意义：你只是在间接操作一个接口变量，而非获得额外能力。
- 接口变量本身存储动态类型和数据指针，加一层指针纯属冗余
- 传参时直接传
io.Reader比传*io.Reader更安全、更符合 Go 习惯 - 若函数签名强制要求
*io.Reader，大概率是设计失误，应优先重构为接收io.Reader
func(*T) String() 和 func(T) String() 对接口实现的影响
当结构体 T 实现某个接口方法时，是否用指针接收器，直接决定 T 和 *T 哪个能赋值给该接口。这是最容易踩坑的地方。
立即学习“go语言免费学习笔记（深入）”；
例如：
type Stringer interface { String() string }<br>type User struct{ Name string }<br>func (u User) String() string { return u.Name } // 值接收器
此时 User{} 满足 Stringer，但 &User{} 也满足（Go 自动解引用）。可一旦改成指针接收器：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func (u *User) String() string { return u.Name }
就只有 *User 满足 Stringer，User{} 直接报错：cannot use User{} (type User) as type Stringer。
- 接口赋值检查发生在编译期，不看运行时值，只看类型声明时的方法集
-
T的方法集只包含值接收器方法；*T的方法集包含值+指针接收器方法 - 如果你导出的结构体预期被用户以值方式使用（如配置结构体），却用了指针接收器实现接口，就会意外破坏兼容性
需要修改底层数据时，必须用指针——但别直接暴露 *interface{}
真有场景要通过接口修改状态，比如一个可重置的计数器：
type Counter interface { Inc(); Reset() }<br>type atomicCounter struct{ v int64 }<br>func (c *atomicCounter) Inc() { atomic.AddInt64(&c.v, 1) }<br>func (c *atomicCounter) Reset() { c.v = 0 }
这里必须用 *atomicCounter 接收器，否则 Reset() 修改的是副本。但对外暴露的仍是 Counter 接口，使用者调用 counter.Reset() 即可，无需知道背后是指针。
- 接口变量内部已含数据地址（对指针接收器实现者而言），使用者无感知
- 不要定义
func(*Counter)这类签名：它要求传入的是「指向接口变量的指针」，极易混淆且无必要 - 如果必须返回可修改的接口实例，返回
Counter即可，内部用指针实现是封装细节
反射中遇到 *interface{} 的真实原因
只有在反射场景下，*interface{} 才可能自然出现——比如用 reflect.ValueOf(&x).Elem() 处理一个接口变量地址时。
示例：
var r io.Reader = os.Stdin<br>v := reflect.ValueOf(&r).Elem() // v.Kind() == reflect.Interface<br>// 此时 v.Type() 是 interface {}，不是 *interface {}
但如果你错误地写了 reflect.ValueOf(&r).Elem().Addr()，就可能得到 *interface{} 类型的 Value，进而触发 panic: reflect: call of reflect.Value.Addr on interface Value。
- 接口值不可取地址（
reflect.Value.Addr()不支持reflect.InterfaceKind） - 想获取底层数据地址？先用
.Elem()解包到具体类型，再判断是否可寻址 - 绝大多数业务代码根本不会也不该碰到
*interface{}，看到它基本意味着反射逻辑绕弯了
接口指针不是语法禁区，而是信号灯：它亮起时，通常说明你正试图绕过 Go 的类型设计直觉，该停下来检查抽象是否合理了。
