Go reflect.TypeFor 怎样复用已有缓冲空间

如果一个泛型辅助函数既要知道 T 的反射类型，又要反复把数据写入调用方已经准备好的 []byte，最容易犯的错误是把这两件事当成同一个“优化开关”。reflect.TypeFor[T]() 只负责拿到类型元数据；缓冲区是否复用，取决于你怎样传递和重置切片。

官方资料：https://pkg.go.dev/reflect#TypeFor

实用做法是：用 reflect.TypeFor[T]() 作为类型计划的稳定键，把反射计算缓存起来；每次调用继续接收 dst []byte，用 dst[:0] 清空长度但保留容量。只要旧结果已经被消费，就能复用底层数组。

先分清 TypeFor 和缓冲区各自负责什么

TypeFor 在 Go 1.22 加入 reflect 包，返回表示类型参数 T 的 reflect.Type。它解决的是“泛型代码怎样取得类型对象”，不是“怎样取得一块可写内存”。因此，下面两个边界应该分别设计：

• 类型边界：把 reflect.TypeFor[T]() 得到的类型作为元数据或缓存键。
• 字节边界：由调用方持有 []byte，通过返回的新切片值接收追加结果。

reflect.Type 值可以比较，也可以作为 map 的键，所以它适合标识“同一种 T 的处理计划”。但不要把 Type 当成结果缓冲区：它描述的是类型，不拥有你的输出字节。

用 TypeFor 缓存类型计划

假设一个小型编码器需要在每条记录前写入类型名。真正昂贵的部分通常是反射元数据整理，而不是把几个字节追加到切片。可以让计划只创建一次，再让每次调用传入自己的输出缓冲区：

package main

import (
	"fmt"
	"reflect"
	"sync"
)

type User struct {
	ID int
}

type recordPlan struct {
	typ   reflect.Type
	label []byte
}

var planCache sync.Map

func planFor[T any]() *recordPlan {
	typ := reflect.TypeFor[T]()
	if cached, ok := planCache.Load(typ); ok {
		// 类型计划只读共享，命中缓存时不再整理同一类型的元数据。
		return cached.(*recordPlan)
	}

	plan := &recordPlan{
		typ:   typ,
		label: []byte(typ.String()),
	}
	actual, _ := planCache.LoadOrStore(typ, plan)
	// 并发首次访问时，以缓存中最终留下的计划为准。
	return actual.(*recordPlan)
}

func appendRecord[T any](dst []byte, payload []byte) []byte {
	plan := planFor[T]()
	// append 会把只读的类型标签复制进调用方提供的 dst。
	dst = append(dst, plan.label...)
	dst = append(dst, '|')
	dst = append(dst, payload...)
	return dst
}

func main() {
	buf := make([]byte, 0, 64)
	buf = appendRecord[User](buf[:0], []byte("id=7"))
	fmt.Println(string(buf))
	// 旧结果已经打印，清零长度即可继续复用同一底层数组。
	buf = appendRecord[User](buf[:0], []byte("id=8"))
	fmt.Println(string(buf))
}

这里的分工很清楚：planFor 只缓存与 User 类型有关的元数据，appendRecord 才操作 dst。LoadOrStore 允许并发首次访问时出现短暂的重复候选，但最终返回的是缓存中实际保存的计划；计划本身在创建后不再修改。

让调用方通过 dst[:0] 复用已有容量

dst[:0] 会保留切片的底层数组和容量，只把长度变成零。它适合放在循环里，但有一个必须写清楚的前提：上一次返回的内容已经被消费，或者已经复制到不会被下一次写入覆盖的地方。

例如写入一个 io.Writer 时，可以让每次 Write 返回后再重置缓冲区：

func writeRecords[T any](w io.Writer, scratch []byte, payloads [][]byte) ([]byte, error) {
	for _, payload := range payloads {
		// 每轮只清空长度，保留 scratch 已有的容量。
		scratch = appendRecord[T](scratch[:0], payload)
		if _, err := w.Write(scratch); err != nil {
			// 返回同一个缓冲区，调用方可以决定是否修复或放弃它。
			return scratch, err
		}
	}
	return scratch, nil
}

如果 w.Write 返回后仍有异步任务持有这段字节，就不能立即复用；这时要么等待消费完成，要么复制一份再交给异步任务：

owned := append([]byte(nil), scratch...)
// owned 拥有独立底层数组，后续重置 scratch 不会覆盖它。

用 allocs/op 验证收益和边界

“复用缓冲区一定更快”并不是可以直接写进结论的事实。输入很短、输出会长期持有，或者类型计划只调用一次时，缓存和所有权管理的复杂度可能不值得。更稳妥的比较方式是准备两个基线：每次重新 make 的版本，以及循环中使用 scratch[:0] 的版本。

go test -run '^$' -bench 'BenchmarkAppendRecord' -benchmem ./...
# 用同一输入比较重新分配版和 scratch[:0] 复用版，不把一次机器结果当成固定倍数。

如果某次输入异常地把容量扩得很大，可以在明确的业务上限下重新分配一块较小的 scratch；如果结果必须跨越下一轮调用保存，则优先复制。TypeFor 的价值是让类型计划更直接、缓存键更稳定，而不是替你决定这些生命周期策略。

常见问题

TypeFor[T] 会自动复用已有 []byte 吗？

不会。它只返回表示 T 的 reflect.Type。缓冲区复用仍然要靠调用方传入切片、使用 dst[:0]，并管理结果的消费时机。

为什么不把 []byte 放进 recordPlan 里全局共享？

全局共享可写缓冲区会把并发调用、结果生命周期和数据覆盖混在一起。类型计划可以共享，但工作缓冲区通常应由一次调用或一个明确的 worker 持有。

TypeFor[T] 能替代 TypeOf(value) 吗？

不能完全替代。TypeFor[T] 读取泛型类型参数；TypeOf(value) 观察接口中已有值的动态类型。手里只有运行时值时，继续使用 TypeOf 更符合问题本身。