值得加//go:inline的是同包非导出、无defer/闭包/select、参数简单、体短且高频调用的纯计算函数，如clampint、fastabs等；跨包、含defer、返回大结构体或涉及接口调用的函数加了也无效。
哪些函数值得加 //go:inline 提示
Go 1.19+ 支持 //go:inline 编译器指令，但它不是“强制内联开关”，而是一种**提示编译器优先考虑内联**的信号。真正起作用的前提是：函数本身已满足内联基本条件（体短、无 defer/闭包/select、参数类型简单、未导出）。否则编译器会直接忽略该提示，并在 -m=2 输出中显示 cannot inline xxx: //go:inline ignored。
适合加提示的典型场景包括：
- 同一包内被高频调用（如每毫秒调用数百次）的辅助函数，比如
clampInt、fastAbs、isPowerOfTwo - 被嵌套在 tight loop 中的纯计算函数，且当前因“略超预算”未被自动内联（
cost 85vs 默认阈值约 80） - 作为接口方法包装层的小函数（如
(*bytes.Buffer).WriteString），你已确认其调用方始终是具体类型而非接口
//go:inline 和 //go:noinline 的实际行为差异
两者不对称：//go:noinline 是强约束，只要存在，编译器一定不内联；而 //go:inline 只是增强倾向，不保证成功。实测中，加了 //go:inline 后仍被拒绝的常见原因有：
- 函数含
defer—— 即使只有一行defer unlock()，也会直接禁用内联 - 返回大结构体（如
struct{ a, b, c, d int64 }）且按值返回，触发逃逸或开销超标 - 跨包调用导出函数（如
json.Unmarshal），即使加提示也无效；必须是同包非导出函数 - 调用链中某环含接口方法调用（如参数是
io.Reader），编译器无法静态确定目标
验证方式始终是 go build -gcflags="-m=2"，看输出是否出现 can inline xxx 或 //go:inline ignored。
为什么不能对所有热函数都加 //go:inline
盲目添加不仅无效，还可能掩盖真实问题：
- 它会让开发者误以为“已优化”，从而忽略更根本的重构机会（比如把含循环的
findMaxInSlice拆成无循环的findMaxOfTwo+ 外层迭代） - 增大二进制体积，尤其当函数被多处调用时，每处都展开一份副本，可能影响 CPU 指令缓存命中率
- 调试体验变差：gdb/dlv 单步时跳过函数边界，堆栈信息丢失，
runtime.Caller获取行号也可能错位 - PGO（Profile-Guided Optimization）阶段可能因内联过度而失去热点函数粒度，反而降低第二阶段优化效果
替代 //go:inline 的更可靠手段
与其依赖提示，不如从代码结构上提高内联成功率：
- 把逻辑拆到调用点附近：例如将
func parseHeader(b []byte) (h Header, err error)中的字段解析逻辑，直接写进 HTTP handler 的 switch 分支里（如果只有一两处调用） - 用指针接收者替代值接收者处理小结构体，避免拷贝开销带来的内联抑制
- 显式传参代替闭包捕获——闭包函数本身无法被内联，且每次创建都分配堆内存
- 对必须保留的复杂函数，用
go:linkname+ 汇编重写关键路径（如 CRC32、base64 编码），这比强行内联更可控
真正难优化的从来不是“能不能内联”，而是“要不要让这段逻辑存在”。//go:inline 是最后一步微调，不是第一反应。
