不能。值接收器的实例是副本，无地址，不满足指针接收器要求；T 的方法集仅含值接收器方法，*T 才包含两者；直接对字面量或短声明变量调用指针方法会报错。
值接收器改不了原值，但能调用指针方法吗？
不能。值接收器的实例是副本，它本身没有地址，无法满足指针接收器方法对 *T 类型的接收者要求。Go 的方法集规则很硬：类型 T 的方法集只包含值接收器方法；而 *T 的方法集包含值接收器和指针接收器方法。
常见错误现象：cannot call pointer method on xxx 或 cannot take the address of xxx，尤其在对字面量或短声明变量（如 foo := MyStruct{}）直接调用指针接收器方法时出现。
- 使用场景：当方法只读字段、不修改状态，且结构体不大（比如
type Point struct{ X, Y int }），值接收器更安全、更清晰 - 参数差异：值接收器传的是拷贝，指针接收器传的是地址——哪怕结构体含切片或 map，值接收器也会复制 header（不是底层数据），但指针接收器才能真正修改字段引用关系
- 性能影响：小结构体（
接口实现时，值 vs 指针接收器决定谁能赋值
接口是否能被某个类型变量满足，取决于该变量的类型是否在方法集里包含了接口所有方法。这直接导致：用值接收器实现接口，T 和 *T 都能赋值；用指针接收器实现，则只有 *T 能赋值，T 会报错 cannot use xxx (type T) as type YYY in assignment。
典型踩坑点：定义了 func (t *MyType) Write(p []byte) (n int, err error) 去实现 io.Writer，结果传 MyType{} 给需要 io.Writer 的函数，编译失败。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 可赋值条件：若接口方法由指针接收器实现，必须传
&v，不能传v - 兼容性影响：库作者若用指针接收器实现公开接口，下游用户就必须取地址；反之，值接收器更宽松，但也可能掩盖意外修改（比如误以为改了原值）
- 建议：导出类型实现标准接口（如
Stringer,error,io.Reader）时，优先用指针接收器——除非你明确希望支持字面量直接赋值且不需修改
嵌套结构体里，匿名字段的方法集怎么继承？
匿名字段提升的是其类型的方法集，而不是“谁实现了它”。也就是说，如果嵌入的是 T，则提升 T 方法集里的方法；如果嵌入的是 *T，则提升 *T 方法集里的方法——二者不等价。
常见错误现象：嵌入 sync.Mutex 后，想在外部类型上调用 Lock()，却写成 type MyStruct struct { sync.Mutex }，然后对 MyStruct{} 实例调用 Lock() 失败，因为 sync.Mutex 的方法全是指针接收器，而 MyStruct{} 是值，没地址可升。
- 正确做法：嵌入
*sync.Mutex，或确保使用&MyStruct{}实例（但后者容易漏） - 本质原因：方法提升只看嵌入字段的类型，不看外围变量如何声明；
T和*T是两个不同类型，方法集不同 - 注意：即使嵌入
*T，也不能自动把外围结构体的值接收器方法“转成”指针调用——仍需保证接收者是可寻址的
什么时候必须用指针接收器？
三种情况绕不开：要修改接收者字段、要实现某个接口且该接口方法已由指针接收器定义、嵌入了指针类型匿名字段并依赖其方法提升。
最容易被忽略的是第三种——很多人只记得“要改字段就用指针”，却忘了嵌入 *http.Client 或 *sql.DB 这类重型对象时，它们自身方法全是指针接收器，不传指针根本调不动。
- 修改字段：哪怕只改一个
count++，也必须用指针接收器，否则改的是副本 - 接口一致性：如果你的类型要满足多个接口，而其中任一接口方法由指针接收器实现，那统一用指针接收器最省心
- 可变性陷阱：值接收器方法里对切片做
append不会影响原切片底层数组（header 拷贝），但对 map 写 key 会生效（map header 含指针），这种不对称行为极易引发 bug
真正麻烦的从来不是语法，而是方法集规则和地址可寻址性之间的隐式耦合——写的时候看不出，运行时报错才回头翻文档。
