内联无法加速reflect.value.call，因其运行时动态派发、含汇编调用、跨包且触发逃逸；有效方案是用reflect.makefunc生成可内联的无反射闭包，彻底绕过call。
内联和反射在 Go 里是反向操作：一个在编译期把函数“展开”，一个在运行时把调用“延迟”。它们无法真正“配合”提升性能——强行混用反而放大缺陷。真实有效的路径只有一条：在热路径上用内联消灭反射，而不是优化反射。
为什么不能用//go:inline加速reflect.Value.Call
因为reflect.Value.Call本身是运行时动态派发，它的整个调用链（参数校验、栈帧重建、类型匹配）都绕过编译器优化。加//go:inline到你自己的包装函数上，只是把一层薄薄的壳展开了，里面那个Call还是照旧慢 100 倍。更关键的是：Call内部调用了runtime.callDeferred等汇编函数，而含unsafe或汇编调用的函数，编译器会直接拒绝内联。
-
//go:inline对跨包函数无效，而reflect包所有导出函数都是跨包的 - 只要函数体里出现
reflect.Value或reflect.Type，它大概率已触发逃逸，而逃逸函数基本不被内联 - 试图内联
Call的调用者，等于在高速公路上给拖拉机装碳纤维外壳——结构瓶颈没动，表面功夫白费
真正能落地的“内联替代反射”方案
不是让反射变快，而是用内联生成的纯函数，彻底绕过reflect.Value.Call。适用前提是：方法签名固定、接收者类型明确、方法名不 runtime 决定。
- 先用
reflect.TypeOf((*MyStruct)(nil)).Method(0).Type拿到目标方法类型 - 再用
reflect.MakeFunc构造一个无反射的闭包，内部做args[0].Interface().(*MyStruct)强转 + 直接调用 - 这个闭包本身可被内联（只要它满足条件），且后续每次调用都不走
Call路径 - 示例中生成的
fn是func(context.Context) error，调用时就是普通函数调用，go build -gcflags="-m=2"能看到inlining call to
哪些地方最容易误以为“能配合”，其实踩了坑
常见幻觉包括：“缓存reflect.Value后内联调用它”“给反射包装函数加//go:inline”“在defer里用反射再试图内联外层”。这些全无效。
-
reflect.Value不能缓存复用——每次Call都新建实例，Value本身不可比较、不能当map键 - 任何含
defer的函数，无论多短，内联直接失败；而日志、锁、错误处理又常带defer，导致你以为的“热点小函数”根本进不了内联流水线 - 用
interface{}接收参数（比如func handle(v interface{})）会阻断内联，哪怕你后续立刻reflect.ValueOf(v)——接口本身就是内联杀手 - 跨包调用默认不内联，所以别把高频反射封装成工具包函数再导出；必须同包、未导出、无接口参数
最易被忽略的一点：内联收益只在纳秒级，而反射开销是百纳秒起跳。想靠内联补反射的洞，就像用创可贴堵水管爆裂——得先关总阀（去掉Call），再考虑局部加固（内联闭包）。否则所有优化都在错误的方向上堆砌。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
