Go 内联优化会被 reflect.Value.Call 直接禁用
只要函数体里调用了 reflect.Value.Call（或任何触发反射调用的路径），Go 编译器就会放弃对该函数做内联。这不是概率问题，是编译器硬性规则——因为反射调用的目标在编译期不可知，无法做静态分析和替换。
常见错误现象：go tool compile -l -m=2 输出中看到 cannot inline xxx: function contains call to reflect.Value.Call，哪怕那行反射代码被 if false 包裹也没用，编译器仍会扫描到。
- 即使只在 debug 分支用反射，也要拆到独立函数里，避免污染主逻辑函数
-
reflect.Value.Call和reflect.Call效果等价，都触发该限制 - 使用
unsafe.Pointer+ 函数指针绕过反射调用，可恢复内联，但失去类型安全，慎用
struct 字段访问走 reflect.StructField 时无法逃逸分析优化
当你用 reflect.Value.FieldByName 或遍历 reflect.Type.Field 获取字段值，编译器无法判断哪些字段实际被读写，会保守地将整个 struct 标记为逃逸到堆上——哪怕你只取一个 int 字段。
使用场景：ORM 映射、配置绑定、通用序列化等需要按名访问字段的代码。
立即学习“go语言免费学习笔记（深入）”；
- 对比直接点访问：
v.X可能栈分配，v.FieldByName("X")几乎必然堆分配 - 字段名字符串字面量（如
"X"）不会被编译器优化掉反射开销，运行时仍要哈希查找 - 如果字段名固定且已知，优先用代码生成（
go:generate）替代运行时反射
interface{} 传参 + reflect.TypeOf 是隐式性能断点
哪怕只是对参数做 reflect.TypeOf(x)，也会阻止编译器对上游函数做某些优化，比如参数消除、常量传播，尤其当 x 来自函数返回值时。
性能影响：不是慢在反射本身，而是它像一堵墙，隔开了前后端的优化链路。实测中，加一行 reflect.TypeOf(v) 可能让某热点函数的汇编输出多出 3–5 条内存加载指令。
- 不要在 hot path 上用
reflect.TypeOf做类型判断，改用类型断言或switch x := v.(type) -
reflect.ValueOf同样触发该问题，且额外增加一次接口转换开销 - 如果必须区分类型，把反射逻辑下沉到独立函数，并用
//go:noinline显式隔离
go build -gcflags="-l" 不能绕过反射导致的内联失败
有人以为关掉内联（-l）就能“统一处理”，其实反而更糟：它让所有函数都失去内联机会，包括那些本可以内联、且完全不碰反射的辅助函数。反射带来的限制是局部的，而 -l 是全局的暴力降级。
真正该做的是精准隔离——把反射逻辑从热路径里物理切出去，而不是用编译开关掩盖设计问题。
- 用
//go:noinline标记含反射的函数，比全局关内联更可控 - 检查
go build -gcflags="-m=2"输出时，重点关注“why”字段，不是看有没有内联，而是看“为什么没内联” - 反射本身不慢，慢的是它迫使编译器放弃优化；所以优化重点永远是“让反射少一点、离核心逻辑远一点”
反射不是黑箱，它是编译器眼里的红灯区。你写的每行 reflect. 都在悄悄改写生成的机器码——这点容易被忽略，直到压测时发现某个本该零分配的函数突然开始频繁 GC。
