interface{}赋值比直接传struct慢3–5倍，因其底层eface需写入类型指针并拷贝或取址，小结构体被迫堆分配，大结构体引入间接寻址，且丧失编译器内联优化机会。
Go 接口本身不带来运行时开销，但接口值的动态分发、类型断言和空接口使用不当会显著拖慢性能。关键不在“能不能用”，而在“怎么用才不掉链子”。
为什么 interface{} 赋值比直接传 struct 慢 3–5 倍
空接口 interface{} 底层是 eface 结构，包含 _type* 和 data 两个指针。每次赋值都要做两件事：写入类型信息指针、拷贝或取地址（取决于值大小）。小结构体（如 struct{a,b int}）被复制进堆；大结构体则只存指针，但仍有额外间接寻址成本。
- 值类型小于 16 字节时，Go 编译器通常直接内联拷贝，但一旦包进
interface{}，就强制走eface路径，失去优化机会 -
fmt.Println(x)看似简单，实则对每个参数都做interface{}装箱 —— 日志高频场景下这是隐性热点 - 避免把高频字段（如 ID、status）反复塞进
interface{}；能用具体类型就别用空接口
iface 动态调用比直接调用慢多少？
非空接口（如 io.Writer）底层是 iface，方法调用需查 itab.fun 数组跳转。这不是虚函数表那种固定偏移，而是 runtime 期哈希查找 + 间接跳转，有缓存未命中风险。
- 基准测试显示：
w.Write(buf)（w是io.Writer接口变量）比直接调用f.Write(buf)（f是 *os.File）慢约 15–25%，尤其在短小 buffer 场景下更明显 - Go 1.21+ 对常见接口（如
io.Writer）做了 inline 缓存优化，但仅限编译器能静态推导的路径；跨包或反射路径仍走完整itab查找 - 若某方法 90% 时间都在调用
Write，且实现类型固定（比如总是*bytes.Buffer），考虑直接传具体类型，绕过接口抽象
指针接收者导致接口无法满足的典型错误
这是最常踩的坑：定义了 func (t *T) M()，却用 T{} 值去赋接口变量，编译直接报错 cannot use T literal (type T) as type X in assignment: T does not implement X (M method has pointer receiver)。
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
立即学习“go语言免费学习笔记（深入）”；
- 值接收者方法：
func (t T) M()→T和*T都能赋给接口 - 指针接收者方法：
func (t *T) M()→ 只有*T能赋，T{}不行，哪怕它字段全零也不行 - HTTP handler 中常见：自定义 struct 实现
http.Handler时用了指针方法，但注册时写了mux.Handle("/x", MyHandler{})—— 这里MyHandler{}是值，必须改成&MyHandler{}
函数转接口：为什么 HandlerFunc 不损耗性能
net/http 里的 HandlerFunc 是函数类型，它通过为该类型定义 ServeHTTP 方法来满足 http.Handler 接口。这种转换零成本 —— 它不新增内存分配，也不引入间接跳转层级。
-
HandlerFunc(f)是类型转换，不是装箱；f本身地址直接存入iface.data，itab指向预生成的函数类型元数据 - 对比
func() {}直接赋给interface{}：前者是类型安全的接口实现，后者是泛型擦除式装箱，多一层eface封装 - 自己封装类似模式时，务必让函数类型的方法接收者是值类型（
func(f HandlerFunc) ServeHTTP(...)），避免又引入指针问题
接口的开销不在语法层面，而在你是否清楚每个赋值、每次断言、每层嵌套背后发生了什么。越靠近底层，越要盯着 iface 和 eface 的内存布局看 —— 它们不是黑盒，是可预测、可规避的确定性成本。
