接口变量存储type和value两部分，底层值是否复制取决于具体类型：bytes.buffer传值则拷贝结构体，*os.file传指针则共享状态；接口仅抽象能力，不改变传递语义。
io.Reader 和 io.Writer 接口值本身没有“值/指针”之分
接口变量存储的是 type 和 value 两部分，底层值是复制还是引用，取决于你传进去的那个具体类型——不是接口决定的，是实现它的类型决定的。
比如 bytes.Buffer 是 struct，传给 io.Reader 时默认按值传递（即拷贝整个 struct）；而 *os.File 是指针类型，传进去的自然就是指针。接口不改变这个行为。
- 传
buf（bytes.Buffer值）→ 接口里存的是bytes.Buffer的副本，读完后原buf不变 - 传
&buf→ 接口里存的是指针，读操作会修改原buf的off字段 - 传
file（已经是*os.File）→ 接口直接持有该指针，所有读写都作用于真实文件句柄
为什么大多数标准库函数接收 io.Reader/io.Writer 而不是具体类型
因为接口抽象了“能读”或“能写”的能力，而不是“怎么读/写”。这让你可以无缝替换底层实现：用 strings.NewReader 测试 HTTP handler，用 gzip.NewReader 包一层解压逻辑，都不用改函数签名。
但要注意：接口无法访问具体类型的字段或方法。比如你传了个 *bytes.Buffer 给 func f(r io.Reader)，在 f 里没法调用 r.Len() 或 r.Reset() —— 那些是 bytes.Buffer 自己的方法，不在 io.Reader 接口里。
立即学习“go语言免费学习笔记（深入）”；
- 想用额外能力？先类型断言：
if buf, ok := r.(*bytes.Buffer); ok { buf.Len() } - 想组合行为？用包装器（wrapper），比如
io.MultiReader、io.TeeReader - 别试图在接口上调用未声明的方法，会编译失败
常见误判：以为 “*os.File 实现了 io.Reader 就必须传指针”
错。真正关键的是：你手里的变量是不是已经是指针。因为 *os.File 是一个指针类型，它实现了 io.Reader；而 os.File（非指针）也实现了 io.Reader，但它不是导出类型，不能直接用。
实际中你几乎总拿到的是 *os.File（比如 os.Open 返回的就是），所以传进去的自然是指针。但这不是接口的要求，是标准库设计的结果。
-
os.Open("x.txt")返回*os.File→ 可直接传给io.Copy(dst, src) -
new(os.File)得到*os.File，也能用；但os.File{}是非法的（没导出字段，无法字面量初始化） - 自定义类型只要实现
Read([]byte) (int, error)方法，无论值接收者还是指针接收者，都能赋给io.Reader
性能提示：小 struct 值传递开销不大，但别盲目取地址
像 bytes.Buffer 这种内部带 slice 的 struct，虽然它是值类型，但 slice 本身包含指针，所以拷贝 bytes.Buffer 不会复制底层数组，只复制 header（3 个 word）。这种“伪值传递”其实很轻量。
但如果你手动加 & 把它变成指针再传，反而可能引入逃逸（尤其在循环里），让 GC 多管一点内存。除非你明确需要共享状态，否则别为了“看起来更高效”而加星号。
- 测试是否逃逸：
go build -gcflags="-m" main.go - 如果函数只是临时读几字节，传值更干净；如果要多次读且希望状态延续（比如解析流），才考虑传指针
- 第三方库若文档没说“需传指针”，就按它示例来——多数情况传值或传指针都行，行为差异来自实现，而非接口
