不是绝对的。值类型封装后方法调用是否零成本取决于内联可能性、逃逸行为和拷贝开销：type别名通常高效，struct封装需权衡语义隔离与性能代价，指针接收者避免大结构体拷贝，interface{}会引发包箱和反射开销。
值类型封装后，方法调用还是零成本抽象吗？
不是绝对的。Go 中对 struct 做一层类型别名（如 type UserID int64）或嵌入字段封装（如 type User struct { id int64 }），方法调用本身不引入运行时开销，但「是否真能内联」「是否触发逃逸」「是否增加拷贝量」取决于具体写法和使用上下文。
- 编译器对
type UserID int64上定义的方法大概率能内联，等价于直接操作int64 - 但若方法接收者是
*UserID，且你传的是临时值（如&UserID(123)），就会触发堆上分配——这比裸用int64多一次逃逸分析判定 - 如果封装体含多个字段（比如
type Email struct { local, domain string }），哪怕只读取local，整个结构体仍按值传递，拷贝成本上升
什么时候该用 type 别名，什么时候该用 struct 封装？
核心看语义隔离强度和后续扩展预期。别名适合「只是换个名字，行为完全一致」；struct 封装适合「要拦住非法构造、预留方法扩展、或未来可能加字段」。
-
type Port uint16：合适。端口号就是无符号16位整数，不需要隐藏内部表示，也不需要额外校验 -
type Password string：危险。看似封装，但用户仍可直接用string赋值，且无法阻止fmt.Printf泄露明文——这时应改用struct { data []byte }并屏蔽字段访问 -
type Timestamp struct { sec, nsec int64 }：合理。为将来支持时区、序列化格式留余地，且可强制所有构造走NewTimestamp()校验逻辑
嵌入 struct 封装时，为什么 receiver 选值类型反而更慢？
因为 Go 的值接收者会复制整个结构体。如果封装体较大（比如含 []byte 或大数组），每次调用都拷贝，性能损失明显；而指针接收者只传地址，但需解引用 + 可能触发逃逸。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 小结构体（≤ 2~3 字段，且都是基础类型）：值接收者通常更快，编译器易内联，无解引用开销
- 含 slice/map/chan/pointer 字段的结构体：必须用指针接收者，否则复制的是 header（如 slice 的 len/cap/ptr），但底层数组不会被复制——这点常被误认为“安全”，实则语义已错乱
- 调试技巧：用
go build -gcflags="-m -m"看是否内联、是否逃逸，比凭经验靠谱
interface{} 接收封装值，会不会悄悄吃掉性能？
会，而且很隐蔽。只要把任何封装值（哪怕是 type ID int）传给接受 interface{} 的函数，就触发接口动态调度 + 数据包箱（iface 转换），即使底层只是个整数。
立即学习“go语言免费学习笔记（深入）”；
- 常见陷阱：
log.Printf("%v", myUserID)—— 这里myUserID被转成interface{}，再反射解析类型，比直接log.Printf("%d", int64(myUserID))慢一个数量级 - 泛型出现后，优先用
func LogID[T ~int64](id T)替代func LogID(id interface{})，避免包箱开销 - 第三方库若要求
interface{}输入（如某些 ORM 的 Scan 方法），封装类型最好提前转回底层类型，而不是依赖类型断言兜底
最易被忽略的点：封装的价值不在编译期，而在代码演化中——但每多一层间接，就多一处逃逸判断、一次内联失败风险、一个调试时多跳一级的栈帧。别为了“看起来更抽象”而封装。
