直接用reflect.Value.Call做字段映射是Excel导出的隐蔽性能杀手：每行触发反射开销，百万行累积超100ms；应缓存类型元数据和字段偏移，用unsafe指针直接取值，将单次耗时从80ns降至2ns，并控制内存布局与对象复用以降低GC压力。
直接用 reflect.Value.Call 做字段映射或方法调用，是大数据量 Excel 导出中最隐蔽的性能杀手——它不显眼，但每行数据都触发一次，百万行就是百万次 100ns+ 的开销，纯反射调用本身就能吃掉 100ms+，更别说参数转换和 receiver 校验带来的内存分配。
为什么导出时用反射取字段会突然变慢
很多导出逻辑写成：遍历每条记录 → reflect.ValueOf(row).FieldByName("Name") → 转成字符串写入。这看似简洁，实则每行都在做三件事：
- 每次
reflect.ValueOf都新建一个reflect.Value结构体（含指针、类型、标志位），触发堆分配 -
FieldByName是线性搜索：struct 字段越多，比对越久；100 字段就要比 100 次字符串 - 取到的
reflect.Value调.String()或.Interface()时，又触发接口转换和逃逸分析不准导致的额外拷贝
结果是：导出 50 万行、20 字段的 struct，仅字段读取就可能占总耗时 40% 以上，且 GC 压力陡增。
缓存 reflect.Type 和字段偏移才是有效解法
真正该缓存的不是 reflect.Value，而是类型元数据和字段位置。因为 reflect.Type 全局唯一，unsafe.Offsetof 计算结果恒定：
立即学习“go语言免费学习笔记（深入）”；
- 用
uintptr(unsafe.Pointer(t))作 key 缓存字段信息，避免t.String()在匿名 struct 或 vendoring 下失效 - 预计算每个字段的
Offset、是否导出、reflect.Type，存成struct{ Offset uintptr; Type reflect.Type; IsExported bool } - 运行时直接
*(*string)(unsafe.Pointer(uintptr(unsafe.Pointer(&row)) + offset))取值，零反射、零接口转换
这种方式下，字段读取退化为指针偏移 + 类型强制转换，耗时从 ~80ns 降到 ~2ns，且不产生 GC 压力。
Excel 写入阶段别让反射参与流式过程
流式导出（如 excelize/v2.StreamWriter）要求低延迟、高吞吐，此时任何反射调用都会打断流水线：
- 不要在
SetRow循环里调reflect.Value.Call执行 getter 方法——哪怕已缓存reflect.Method，Call本身仍需校验 receiver 可寻址性、转换参数数组 - 更优做法：初始化时用
reflect.MakeFunc生成闭包，把 getter 方法“编译”成普通函数，后续直接调用 - 若字段逻辑简单（如只取字段值），干脆放弃反射，用代码生成工具（如
stringer或自定义模板）提前生成访问器，彻底脱离运行时成本
注意：MakeFunc 生成的闭包不能用于签名动态变化的场景，但导出结构体字段基本固定，正适合。
最容易被忽略的点：反射只是表象，内存布局和 GC 才是瓶颈根因
即使你把 reflect.Value.Call 全部干掉，如果导出 struct 本身字段顺序混乱（比如 byte 放最前、int64 放最后），CPU 缓存行利用率仍会很低；而高频小对象分配（如每行 new 一个 []interface{}）会让 GC 频繁 STW。所以优化必须两头抓：一头用偏移访问绕过反射，另一头用内存对齐 + 对象池控制结构体布局和复用。
