值类型变量能直接调用指针接收者方法，是因为编译器在v可寻址时将v.Method()重写为(&v).Method()，属语法糖；不可寻址（如字面量、map元素、函数返回值）则必须显式取址。
值类型变量能直接调用指针接收者方法，不是因为 Go “自动转成指针”，而是编译器在满足可寻址前提下，把 v.Method() 重写为 (&v).Method() —— 这是语法糖，不是类型转换，也不改变方法集规则。
为什么 v.Method() 能调用指针接收者方法？
Go 规范明确允许：当 v 是可寻址的（比如局部变量、结构体字段、切片元素），且 &v 的方法集包含该方法时，v.Method() 就是合法简写。
它不依赖“值类型是否实现了接口”，也不改变 Vertex 和 *Vertex 是两个不同类型的事实。只是调用层面的便利设计。
-
v := Vertex{1, 2}✅ 可寻址 →v.Scale(2)合法 -
Vertex{1, 2}.Scale(2)❌ 字面量不可寻址 → 编译报错cannot call pointer method on Vertex literal -
getV().Scale(2)❌ 函数返回值（非地址逃逸）不可寻址 → 同样报错
v.Method() 和 (&v).Method() 有区别吗？
语义上完全等价，性能无差异——这是纯编译期重写，不引入任何运行时开销。
立即学习“go语言免费学习笔记（深入）”；
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
但理解区别对写出健壮代码很关键：
- 若
v是 map 元素（如m["k"].Method()），会报错：map 元素不可寻址，必须先赋给局部变量再调用 - 若
v是接口变量（如var i interface{} = Vertex{1,2}; i.(interface{Method()}).Method()），运行时 panic：底层值不可寻址，无法隐式取址 - nil 指针调用指针接收者方法不会编译失败，但若方法体内解引用了
nil，就会 panic —— 这和“能否调用”是两回事
什么时候必须显式写 &v？
只要 v 不可寻址，就必须显式取址或改用变量承载。常见场景包括：
- 字面量直接调用：
Vertex{1,2}.Scale(2)→ 改成((&Vertex{1,2}).Scale(2))或先赋值v := Vertex{1,2}; (&v).Scale(2) - 函数返回值：
parseVertex().Scale(2)→ 改成v := parseVertex(); (&v).Scale(2) - 需要传给只接受
*T的函数或接口时（如某接口方法由指针接收者定义），v不能直接赋值，必须用&v
接口赋值时指针和值的匹配规则
接口是否能接收某个值，取决于该值的类型是否拥有完整的方法集。而方法集严格按接收者类型划分：
- 若接口方法由
func (t *T) M()定义，则只有*T类型（或可寻址的T变量）能赋值给该接口 -
T{...}字面量不能直接赋给该接口；var t T; i = &t才行 - 值接收者方法（
func (t T) M()）会被T和*T同时拥有，所以更宽松
最容易被忽略的是：接口变量本身不保存“是否可寻址”的元信息。一旦值被装入接口，再想通过接口调用指针接收者方法，就要求原始值当时就是可寻址的（比如是变量地址），否则 panic —— 这个约束不在编译期检查，得靠经验规避。
