在go中，值接收者操作的是结构体的副本，对字段（如`bytes.buffer`）的修改不会影响原始实例；而指针接收者直接操作原结构体，可持久化状态变更——这是解决“方法看似执行却无效果”问题的关键。
在你的 SecureReader 示例中，问题根源在于接收者类型的选择：
func (s SecureReader) Read(b []byte) (int, error) {
s.decryptPipeIntoBuffer() // ← 此处调用的是值接收者版本
return s.decrypted.Read(b)
}当 decryptPipeIntoBuffer() 使用 值接收者（func (s SecureReader) decryptPipeIntoBuffer()）时，Go 会将整个 SecureReader 实例（含 decrypted bytes.Buffer 字段）复制一份传入方法。即使该方法内部向 s.decrypted 写入了数据，这些写入仅发生在副本上；方法返回后，副本被销毁，原始 SecureReader 的 decrypted 缓冲区仍为空——因此后续 s.decrypted.Read(b) 立即返回 io.EOF。
而改为 指针接收者 后：
func (s *SecureReader) decryptPipeIntoBuffer() (int, error) {
// s 是指向原始实例的指针
// s.decrypted.Write(...) 将真实修改原始缓冲区
}此时 s 指向原始 SecureReader 实例，所有对 s.decrypted 的操作（如 Write, WriteString, Grow 等）都会直接影响原始字段，确保状态被正确缓存和复用。
立即学习“go语言免费学习笔记（深入）”；
✅ 正确实践建议：
- 凡需修改结构体字段的方法，必须使用指针接收者（如状态更新、缓存填充、资源初始化等）；
- 若结构体较大（如含大数组、切片或嵌套结构），优先用指针接收者避免不必要的内存拷贝；
- 保持一致性：若某结构体已有任一方法使用指针接收者，其余方法也应统一使用指针接收者，避免意外行为差异（例如接口实现不一致）；
- 只读方法（如 String() string, Len() int）可用值接收者，但小结构体上性能差异微乎其微，通常仍推荐指针以保证统一性。
⚠️ 注意：bytes.Buffer 本身是引用类型（底层为 slice），但 SecureReader.decrypted 是一个 值字段 —— 它的复制会复制其内部的 []byte header（包含指针、长度、容量），因此副本与原字段初始共享底层数组；但一旦发生扩容（如 Write 超出容量），副本会分配新底层数组，进一步加剧状态不一致。因此，不能依赖“slice 是引用类型”来规避指针接收者需求——结构体字段本身的复制语义才是决定性因素。
简言之：接收者类型不是语法糖，而是明确表达“是否需要写入原始实例”的契约。选择错误，轻则逻辑失效，重则引发难以调试的并发或状态问题。
