确认函数真没被内联的唯一可靠方式是运行go build -gcflags="-m=2"并查看输出中是否出现inlining call to xxx；仅can inline xxx表示候选但未实际插入，跨包调用、含interface{}、闭包、defer等均直接禁止内联。
Go 函数调用本身开销极小，单次 call + ret 指令在现代 CPU 上约 1–3 ns；但你测到的“函数调用慢”，99% 不是调用指令的问题，而是内联被禁、逃逸发生、接口查表或反射介入导致的间接成本。
怎么确认函数真没被内联？
Go 编译器默认对小函数自动内联，BenchmarkX 跑出来耗时接近 0，很可能不是“快”，而是根本没调用——函数体被直接展开进调用方了。必须验证内联状态，否则 benchmark 失去意义。
- 加
//go:noinline注释到目标函数前，强制它不被内联，再跑 benchmark 对比基线 - 用
go build -gcflags="-m -l" main.go看编译日志：出现inlining call to add才算真内联；只有can inline add说明候选但未插入 - 跨包函数默认不内联，除非加
//go:export或用-gcflags="-l=4" - 含
interface{}、闭包、指针解引用、或返回值逃逸的函数，基本不会内联
值接收者方法 vs 普通函数，谁更快？
两者汇编级调用开销一致，都是普通 call 指令；差异只来自接收者是否逃逸、能否内联，以及结构体大小带来的复制成本。
- 小结构体（≤16 字节，如
type Point struct{ x, y int32 }）：值接收者方法和等效纯函数性能几乎一样，编译器会优化掉冗余复制 - 大结构体（>64 字节）：指针接收者方法明显更优，避免栈上整块拷贝；但若指针逃逸（如存入全局 map），反而因无法内联而比值接收者还慢
-
User{}.SetName("x")在指针接收者下会编译失败，而纯函数SetName(User{}, "x")总是合法——这不是性能问题，但影响调用模式和重构安全
接口调用和反射调用为什么慢得明显？
接口调用慢在 itab 查表 + 间接跳转；反射调用慢在运行时全链路重建，二者都绕过了编译期绑定，无法内联，且每调用一次都要走 runtime 黑盒。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 接口调用（如
w.Write(p)）：每次执行需调用runtime.ifaceE2I解包类型，再从 itab 取函数指针，比直接调用多 2–3 条指令，实测慢 1.5–2 倍 - 反射调用（如
v.MethodByName("Handle").Call()）：单次开销 80–120 ns，比直接调用慢 50–100 倍；原因包括参数校验、内存拷贝、栈帧手动构造、GC 安全点插入 - 高频通道分发中混用
reflect.ValueOf(msg).MethodByName(...).Call()是典型雪崩点，应改用初始化阶段预生成闭包或 unsafe 方法地址缓存
defer 和 cgo 的隐性开销容易被忽略
它们不体现在 call 指令数里，但 runtime 层面成本真实存在，且在热路径中放大明显。
-
defer开销不在汇编指令，而在runtime.deferproc分配结构体（栈或堆）、写入 fn 指针与参数快照、原子更新 goroutine 的_defer链表头；简单defer mu.Unlock()仍比裸调用慢 2–3 倍 - cgo 调用单次开销 50–200 ns：需暂停 goroutine 调度、切换 OS 线程、适配 C ABI、处理 Go/C 字符串/切片边界拷贝；仅当 C 计算耗时 ≥ 100× 调用开销时才值得引入
- 无参无返函数仍有完整栈帧：含返回地址（8 字节）、可能的 defer 元数据、ABI 对齐填充；
call指令本身就会压入返回地址，这是硬件行为，不可省略
真正决定“函数调用快不快”的，从来不是那条 call 指令，而是它背后有没有触发逃逸、是否被内联、是否经过接口或反射的运行时路径——这些才是你在火焰图里看到 runtime.ifaceE2I 或 runtime.reflectcall 占比飙升的原因。
