interface{}比较不会触发逃逸，但会进行itab哈希比对和值比较，不可内联；类型不同时立即返回false，相同时若值不可比较则编译报错；泛型可规避该开销。
interface{} 比较操作会触发 itab 查找和逃逸吗？
不会直接逃逸，但每次 == 或 != 比较两个 interface{} 值时，Go 必须检查它们的类型是否一致、底层值是否相等。这涉及 itab 的哈希比对和值内存逐字节比较（若类型支持），属于轻量级运行时开销，但**不可内联**，且在热路径中累积明显。
- 如果两个
interface{}的动态类型不同，比较立即返回false，不比较值 - 如果类型相同且是可比较类型（如
int、string、struct{}），则比较底层值；若值在栈上，不额外分配 - 如果类型相同但值是不可比较类型（如
map、slice、func），==编译报错 —— 这是编译期拦截，不是运行时陷阱 - 常见误用：把
map[string]interface{}里的字段反复用==判断是否为nil，实际应先断言再比，否则每次都在做类型一致性校验
为什么 if val == nil 对 interface{} 可能失效？
因为 interface{} 是双元组（类型 + 值），只有两者都为 nil 才算真 nil。你赋一个 *T 类型的 nil 指针给 interface{}，它的类型部分非空，整个接口就不等于 nil —— 这不是 bug，是设计使然。
- 典型场景：
var err *MyError = nil; data := interface{}(err)→data == nil为false - 正确判断方式不是
if data == nil，而是if data == nil || reflect.ValueOf(data).IsNil()（仅调试用）或更稳妥地：先类型断言再判空 - 最安全做法：避免让
interface{}承载指针类型值；若必须，工厂函数里显式转成nil接口：if p == nil { return nil }，而不是return p
用泛型替代 interface{} 能规避比较开销吗？
能，而且效果显著。泛型函数在实例化后，类型信息已知，编译器可生成专有代码，绕过 itab 查询和接口装箱，比较直接走原生指令。
- 例如：
func Equal[T comparable](a, b T) bool { return a == b }，调用Equal[string]("x", "y")不经过任何接口机制 - 注意
T comparable约束：仅适用于可比较类型；若需支持map或slice，得另写逻辑，但此时本就不该用== - 性能差异实测：在百万次循环中，
interface{}比较比泛型版本慢 3–5 倍，pprof 显示热点集中在runtime.ifaceeq - 迁移提示：不要全局替换，优先改热路径（如 JSON 解析后的字段校验、RPC 参数预检）
map[string]interface{} 中的 interface{} 值比较为何特别危险？
因为 map 查找本身已带哈希计算开销，再叠加每次取值后的 interface{} 比较，会把单次操作放大成双重间接开销。更糟的是，这类 map 常被序列化/反序列化，导致值反复装箱。
立即学习“go语言免费学习笔记（深入）”；
- 错误模式：
if m["status"] == "success"→ 先从 map 取出interface{}，再做接口比较 - 推荐写法：
if s, ok := m["status"].(string); ok && s == "success"，一次断言+原生字符串比较 - 若字段类型固定，用结构体解析（
json.Unmarshal到 struct）比map[string]interface{}快 2–3 倍，且无运行时类型模糊问题 - 切记：
map[string]interface{}是动态场景的妥协方案，不是通用数据容器；生产环境高频访问字段务必固化类型
interface{} 出现在循环、条件分支或高频 IO 路径里，就得问一句：这里有没有更早确定类型的可能。 
