go 中结构体的值接收方法在调用时会隐式复制整个结构体，若此时另一 goroutine 正在修改该结构体（如写入字段），则复制操作构成“读”，与并发写形成数据竞争。
go 中结构体的值接收方法在调用时会隐式复制整个结构体，若此时另一 goroutine 正在修改该结构体（如写入字段），则复制操作构成“读”，与并发写形成数据竞争。
在 Go 并发编程中，竞态条件（race condition）不仅出现在显式的字段读写上，也可能由隐式内存访问触发。上述代码看似安全——version() 方法既不读也不写任何字段，仅返回常量 1，但 go run -race 仍报告竞态：Write at rpc.result = 42 与 Previous read at version := rpc.version()。问题根源在于 Go 方法调用的接收者语义。
值接收者触发结构体复制，构成隐式读操作
当方法定义为 func (RPC) version() int（值接收者）时，每次调用 rpc.version() 都会将 rpc 的整个结构体实例按值传入。即使方法体内未显式访问任何字段，编译器仍需执行一次完整的内存拷贝（copy of the struct）。而 rpc 是一个指向堆上 RPC 实例的指针（rpc := &RPC{...}），所以 rpc.version() 实际等价于：
tmp := *rpc // ← 这里发生一次完整结构体读取（即“read”事件） tmp.version() // 然后在副本上调用方法
该读取操作（*rpc 解引用）正是 race detector 捕获的“previous read”。与此同时，后台 goroutine 执行 rpc.compute()，对同一内存地址执行 rpc.result = 42（写操作）。读与写发生在同一内存区域（rpc.result 所在结构体起始地址），且无同步机制，因此构成数据竞争。
指针接收者避免复制，消除隐式读
将接收者改为指针类型 func (*RPC) version() int 后，调用 rpc.version() 不再复制结构体，而是直接传递指针值（即地址本身）：
// 等价于： version := (*RPC).version(rpc) // 仅传递指针，不访问结构体内容
由于方法体内未解引用指针（未执行 (*rpc).result 或类似操作），不产生任何对结构体字段的读取，自然不会与 rpc.result = 42 形成竞争。注意：此处的“指针传递”本身是原子的、无共享内存访问的纯值传递，不触发 race detector。
关键注意事项
- ✅ 安全前提：指针接收者方法只有在完全不访问结构体字段时才绝对无竞态。一旦出现 return rpc.result 或 fmt.Println(rpc.done)，仍会触发读操作，若该字段被并发写，竞态重现。
- ✅ 字段隔离可缓解：若结构体含多个字段，且某字段（如 dummy int）从不被并发修改，则对其的读取（rpc.dummy）不会与 rpc.result 的写入竞争——race detector 仅检测同一内存地址的冲突读写。
- ⚠️ 性能与语义权衡：值接收者适合小型、不可变、无内部指针的结构体（如 type Point struct{X,Y float64}）；但涉及并发或较大结构体时，指针接收者更安全、高效。
总结
竞态的本质是对同一内存位置的非同步读写。值接收方法强制结构体复制，该复制即为一次“读”，无论方法体是否使用字段。这是 Go 内存模型的底层行为，而非逻辑错误。因此，在并发场景下，除非明确需要值语义（如防止方法意外修改原值），否则优先使用指针接收者，并确保方法内对字段的访问符合同步约定。启用 -race 标志不是可选项，而是并发开发的必备实践。
