不会。值接收者方法内修改字段只作用于副本，原始结构体不变；必须用指针接收者才能修改原值，且影响方法集与接口实现一致性。
值接收者方法里改字段，原始结构体变了吗
不会。值接收者方法内部对结构体字段的修改，只作用于该方法接收参数的副本，原始变量完全不受影响。
这是 Go 值语义的直接体现：调用时 func (s MyStruct) Modify() 会把 s 拷贝一份传进去，后续所有操作都发生在副本上。
- 常见错误现象：
user.SetName("Alice")调用后user.Name还是空字符串，以为方法没生效，其实是用了值接收者却期待指针效果 - 使用场景：适合只读操作，比如
func (p Point) DistanceFromOrigin() float64，不改变p本身 - 性能影响：小结构体（如
struct{ x, y int }）拷贝开销小；大结构体（含切片、map 或大量字段）会明显拖慢，且修改无效更难调试
什么时候必须用指针接收者
只要方法需要修改接收者的字段，就必须用指针接收者——没有例外。
Go 不允许在值接收者方法里“偷偷”改原值，它连这个机会都不给：编译器会静默忽略字段赋值，或者（在较新版本中）直接报错 cannot assign to struct field（取决于字段是否可寻址）。
立即学习“go语言免费学习笔记（深入）”；
- 常见错误现象：
func (u User) SetID(id int) { u.ID = id }编译通过但无效；升级 Go 后可能提示cannot assign to u.ID - 参数差异：
func (u *User) SetID(id int)中u是指针，u.ID等价于(*u).ID，能真正写入原内存位置 - 接口实现一致性：如果某个接口方法用了指针接收者，那么只有
*T类型能实现它，T类型不能——这点常被忽略，导致var i Interface = myStruct编译失败
值接收者 vs 指针接收者：方法集和接口匹配
这不是风格选择，而是类型系统硬性规则。值类型 T 和指针类型 *T 的方法集不同，直接影响能否赋值给接口变量。
例如定义了 func (t *T) M()，那只有 *T 满足接口；若只定义了 func (t T) M()，则 T 和 *T 都满足（因为 *T 可自动解引用调用值方法）。
- 使用场景：想让结构体变量和指针变量都能赋给同一接口？只用值接收者。但前提是方法不改状态
- 兼容性影响：混用两者极易出问题。比如标准库
sync.Mutex所有方法都是指针接收者——你传sync.Mutex{}给需要sync.Locker的函数会编译失败 - 容易踩的坑：写了
func (t T) Save()，后来加了个func (t *T) DirtyMark()，结果T类型突然无法满足原来那个只依赖Save的接口了（因为方法集变了）
怎么快速判断该用哪个接收者
看方法签名第一眼就该有答案：方法体里有没有写 =、++、--、或调用其他会改接收者的方法？有，就只能用指针；没有，再看结构体大小和是否要统一接口实现。
- 实操建议：默认先写指针接收者。90% 的业务方法要么要改字段，要么未来会扩展为修改状态，提前用指针省去重构成本
- 例外情况：纯计算型小结构体（如
type RGB [3]uint8），值接收者更清晰且无性能负担 - 检查技巧：用
go vet能捕获部分无意义的字段赋值（如值接收者里改字段但未使用），但无法替代逻辑判断
最麻烦的不是选错，而是同一个类型里混用两种接收者又没意识到方法集分裂——这时候接口赋值失败，错误信息里根本不会提“接收者类型”，只会说“T does not implement X (missing Y method)”，得倒回去一行行核对方法签名。
