测试时传指针更难写，因其引入外部可变状态导致测试污染、并发不安全、mock复杂；应优先用值接收者，仅当需修改接收者本身或大对象性能敏感时才用指针。
为什么测试时传指针反而让单元测试更难写
因为指针会把外部状态带进测试作用域，导致测试间相互污染。比如一个函数接收 *sync.Mutex 或 *sql.DB，你没法在测试里轻易控制它的内部状态，也无法安全地并发运行多个测试用例。
- 值类型（如
struct{}、int、string）天然隔离，每次传参都是副本，测试互不干扰 - 指针类型若指向可变结构（如含
map、slice、chan的 struct），测试中修改它会影响其他测试或后续断言 - Mock 依赖时，如果接口方法签名强制要求指针接收者，你就得构造真实实例或绕过接口直接测实现——这违背了“面向接口测试”的初衷
什么时候必须用指针接收者才不影响可测试性
仅当方法需要修改接收者本身（不是字段），且该修改是业务语义的一部分时，才应使用指针接收者。否则，优先用值接收者 + 返回新值，测试更干净。
-
func (s Score) Add(n int) Score比func (s *Score) Add(n int)更易测：输入确定 → 输出确定，无副作用 - 若类型较大（如含大 slice 或 map），值拷贝开销高，才考虑指针接收者——但此时应把可变状态封装进私有字段，并通过纯函数式 API 暴露行为
-
标准库中
time.Time是值类型，所有方法都是值接收者；而bytes.Buffer是指针接收者，因为它必须 mutate 内部[]byte
接口定义如何暴露指针/值依赖风险
接口本身不声明接收者类型，但实现它的具体类型决定了调用方是否能传值或必须传指针。一旦接口被广泛使用，就很难再把指针接收者改成值接收者——会导致大量调用点编译失败。
- 定义接口前先问：这个行为是否应该允许“无状态调用”？如果是，就让实现用值接收者，接口方法签名也自然兼容值和指针
- 避免在接口中暴露对
*T的强依赖，比如写func Do(*T)而非func Do(T)—— 这会让 mock 实现必须分配堆内存，增加测试复杂度 - 测试时若发现某个接口只能用指针调用，大概率说明它隐含了状态变更契约，需检查是否真有必要
gomock / testify mock 时指针带来的典型问题
用 gomock 生成 mock 时，如果原接口由指针接收者实现，mock 对象也必须是指针类型；而你传给被测函数的若是个值，Go 会静默取地址——但这个地址只在当前作用域有效，容易引发 panic 或未定义行为。
立即学习“go语言免费学习笔记（深入）”；
type Service interface {
Fetch() string
}
// 正确：值接收者，mock 可以是值或指针
func (s ServiceImpl) Fetch() string { return "ok" }
// 危险：指针接收者，mock 必须是指针，且被测代码必须传 &mockObj
func (s *ServiceImpl) Fetch() string { return "ok" }
- 用
testify/mock时，若 mock 对象字段含指针（如db *sql.DB），记得在SetupTest中重置，否则测试间共享连接池状态 - 对第三方库接口（如
io.Reader）做 mock，尽量用值包装（如struct{ io.Reader }），避免直接嵌入指针字段
type ID int 和 func (id *ID) String() string 看似无害，但会让所有使用 ID 的地方被迫传地址，破坏值语义的可预测性。 
