Go无法替换runtime内存分配器，只能在生命周期明确、对象不逃逸的场景下手动实现Arena内存池，通过unsafe.Pointer偏移分配并显式回收。
Go 里没法直接替换 runtime 的内存分配器
Go 运行时强制使用自己的 mallocgc 和堆管理逻辑，所有 new、make、结构体字面量、切片扩容等操作都绕不开它。你写不出一个“全局生效”的自定义分配器——这不是权限问题，是设计使然。
所以真实可行的路径只有一条：在特定生命周期明确、对象不逃逸、不跨 goroutine 共享的场景下，自己管理一块连续内存（即 Arena），手动布局、复用、批量释放。
- 典型适用场景：一次请求处理中临时生成大量小对象（如解析 AST 节点、构建中间表达式树）
- 不适用场景：需要 GC 跟踪的对象、长期存活的缓存、被闭包捕获的变量
- 关键前提：所有分配的对象必须是值类型或指针不逃逸到堆外；否则 arena 一回收，指针就变 dangling
用 unsafe + reflect 手动实现 Arena 分配
标准库没提供 Arena 类型，得自己封装。核心是申请一大块 []byte，用指针算术做偏移分配，靠 unsafe.Pointer 转成目标类型指针。
注意：reflect.New 或 unsafe.Slice（Go 1.21+）不能直接用于 arena 内存——它们仍会触发 GC 标记。必须用 unsafe.Add + (*T)(unsafe.Pointer(...)) 强转。
立即学习“go语言免费学习笔记（深入）”；
- 分配前检查剩余空间，避免越界（建议预设对齐边界，如 8/16 字节）
- 不要用
defer注册 cleanup——arena 回收应显式调用，且需确保无活跃引用 - 结构体字段顺序影响布局大小，用
unsafe.Offsetof验证实际占用，别信sizeof直觉
type Arena struct {
data []byte
off uintptr
}
func (a *Arena) Alloc[T any]() *T {
sz := unsafe.Sizeof(*new(T))
if a.off+sz > uintptr(len(a.data)) {
panic("arena full")
}
p := unsafe.Add(unsafe.SliceData(a.data), a.off)
a.off += sz
return (*T)(p)
}
sync.Pool 不是 Arena，但常被误用作替代方案
sync.Pool 管理的是「可复用对象」，不是「连续内存块」。它底层仍是调用 runtime 分配器，只是延迟了 GC 回收时机。对象可能被任意 goroutine 拿走、修改、长期持有，无法保证生命周期可控。
- 如果你需要的是“本次处理完立刻全部释放”，
sync.Pool无法满足——它的Put只是放回池子，不释放内存 - 如果你的对象带指针（比如含
string或slice字段），放进sync.Pool后，其底层数组仍受 GC 管理，arena 的零拷贝优势全丢 - 真正适合
sync.Pool的是固定大小、无指针、构造开销大的对象（如bytes.Buffer），而非 arena 场景
arena 回收时最易忽略的逃逸点
最隐蔽的坑不是分配，而是“你以为它没逃逸，其实它逃了”。哪怕只有一处把 arena 分配的指针传给了 fmt.Printf、log.Print、或者作为 map value 存储，runtime 就会把它标为堆对象，后续 arena 释放后触发 use-after-free。
- 用
go build -gcflags="-m"检查关键变量是否逃逸；关注输出里的moved to heap - 禁用所有反射操作（
fmt系列重度依赖反射），日志改用io.WriteString等无反射方式 - 避免在 arena 对象上定义方法——接收者若为指针，方法可能被接口隐式转换捕获，导致逃逸
arena 的边界很硬：要么全链路控制住生命周期，要么干脆别用。中间状态最危险。
