在go中，值接收者操作的是结构体的副本，修改不会影响原实例；指针接收者则直接操作原实例，支持状态变更。选择不当会导致方法看似执行却无效果（如缓存未更新、字段未修改），这是初学者常见陷阱。
在go语言中，方法接收者类型（func (s T) Method() vs func (s *T) Method()）不仅关乎性能，更决定方法能否真正改变接收者的状态。以你的 SecureReader 为例：
type SecureReader Struct { pipe io.Reader shared *[32]byte decrypted bytes.Buffer // 可变状态：需写入解密数据 }当你使用值接收者定义 decryptPipeIntoBuffer：
func (s SecureReader) decryptPipeIntoBuffer() (int, error) { n, err := io.copy(&s.decrypted, s.pipe) // ✅ 编译通过，但... s.pipe = nil // ❌ 修改的是副本的 pipe 字段 return n, err }此时 s 是调用时 SecureReader 实例的一份完整拷贝（包括 decrypted 字段的副本）。io.Copy(&s.decrypted, …) 实际写入的是副本中的 bytes.Buffer，而原始 s.decrypted 完全未被触碰。方法返回后，副本被销毁，所有变更（如缓冲区内容、字段赋值）全部丢失——这正是你反复遇到 io.EOF 的根本原因：decrypted.Read(b) 始终读取一个空的、未填充的原始缓冲区。
而改为指针接收者后：
立即学习“go语言免费学习笔记（深入）”；
func (s *SecureReader) decryptPipeIntoBuffer() (int, error) { n, err := io.Copy(&s.decrypted, s.pipe) // ✅ 写入原始实例的 decrypted if err == nil { s.pipe = nil // ✅ 修改原始实例的 pipe 字段 } return n, err }s 是指向原始 SecureReader 实例的指针，&s.decrypted 即原始缓冲区地址，所有写入和字段修改均作用于调用方持有的真实对象。
✅ 何时必须使用指针接收者？
- 方法需修改接收者字段（如填充缓冲区、更新状态标志、重置计数器）；
- 接收者是大结构体（避免拷贝开销，例如含大数组、切片或 map 的 struct）；
- 类型已存在其他指针接收者方法（保持接口一致性，避免混用引发意外行为）。
⚠️ 注意事项：
- 即使方法只读，若结构体过大（如 >16 字节），也建议用指针接收者提升性能；
- bytes.Buffer 本身内部含切片字段，其 Write 方法已是指针接收者——这意味着你调用 s.decrypted.Write(…) 时，隐式依赖了指针语义；若 s 是值接收者，该调用仍生效（因 s.decrypted 是副本，但其底层切片头仍指向同一底层数组），但 s.decrypted 的长度/容量等元信息变更不会同步回原实例，极易引发逻辑错误；
- Go 不允许对值接收者方法进行“地址获取”：var sr SecureReader; _ = &sr.Read 会编译失败，而 (*SecureReader).Read 总是合法的。
总结： 将接收者视为方法的第一个隐式参数——func Read(s SecureReader, b []byte) 和 func Read(s *SecureReader, b []byte) 的语义差异，与普通函数参数传递规则完全一致。当方法需“写入”接收者状态时，务必选用 *T；若仅作纯计算且结构体小巧，T 亦可，但实践中优先考虑指针接收者更安全、更统一。