内联是仅在函数位于热点路径且未被自动内联时才适用的低层优化手段；需通过go build -gcflags="-m=2"确认实际内联结果，而非依赖//go:inline或函数简洁性。
内联不是“学了就能用”的技巧，而是只有在确认函数真正在热点路径上、且当前未被内联时，才值得介入的低层优化手段；盲目加 //go:inline 或重写函数几乎从不提升性能，反而常让二进制变大、调试变难。
怎么确认目标函数到底有没有被内联
别看函数多短、多简单，唯一可信的是编译器输出。运行：
go build -gcflags="-m=2" main.go 2>&1 | grep "inlining call to"
如果出现类似 ./main.go:42:15: inlining call to parseHeader，说明它真被展开了；只看到 can inline parseHeader 不代表成功——那只是编译器“觉得可以”，但后续成本模型可能否决它。
-
-m=2必须带等号，-m或-m=1不显示内联决策细节 - 跨包调用（如
strings.TrimSpace）默认不内联，//go:inline对它无效 - 基准测试（
go test -bench=.）默认强制加-gcflags="-l"（禁用所有内联），你在 bench 里测不到真实效果
哪些写法会让内联直接失败（加 //go:inline 也救不了）
Go 编译器有一套硬性拦截规则，命中任意一条就放弃，不讲情面：
立即学习“go语言免费学习笔记（深入）”；
- 函数里有
defer、panic、recover——哪怕只有一行defer mu.Unlock() - 用了闭包且捕获外部变量，例如
func() int { return x + y }中的x、y来自外层作用域 - 返回值是接口类型（如
interface{}）或方法集非空的结构体 - 含
reflect、unsafe，或调用了标有//go:noinline的函数 - 是递归函数，或调用链中某环含接口方法（如参数是
io.Reader）
这些和函数行数无关，也和你加没加 //go:inline 无关。
Golang Samber Hot
下载
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
//go:inline 怎么写才可能生效
它不是开关，是 pragma 指令，语法和位置极其敏感：
- 必须紧贴函数声明正上方，中间不能有空行、不能有其它注释隔开
- 只对同包、未导出（小写首字母）函数有效；对导出函数、接收者为接口类型的方法（如
func (i MyInterface) Foo()）加了也白加 - 函数本身得先满足基本条件：体短、无
defer/闭包/select、参数和返回值类型简单、不逃逸 - 典型可提示场景：同包高频调用的纯计算函数，如
clampInt、fastAbs、isPowerOfTwo
错误写法示例：
// 这里有个空行
//go:inline
func add(a, b int) int { return a + b }
这种写法编译器直接忽略。
内联真正起作用的边界在哪
它只在极窄场景下有意义：每秒调用上万次、函数体极小（如 max、clamp）、且无内存分配。实测收益通常在 0.3–1.5 ns/op 级别。
- HTTP handler 里一个
if err != nil { return err }被内联，省下的是一次跳转开销；但为此把parseRequest拆成五个小函数，反而破坏可读性，还可能因逃逸分析恶化导致堆分配增多 - 内联后二进制体积可能明显增大：一个被调用 10 次的函数，会复制出 10 份指令；若它调了
json.Marshal，整个encoding/json符号链都会被拖进来 - 调试体验变差：
dlv单步时跳过函数边界，runtime.Caller获取的行号也可能错位
真正该优先做的，是用 pprof 定位真实热点，再看是不是函数调用本身成了瓶颈——大多数时候，卡点其实在内存分配、接口断言、切片扩容或锁竞争上，而不是函数跳转。
