&v escapes to heap 表示编译器确定局部变量 v 的地址被逃逸，必须分配到堆上，而非栈上；常见原因包括赋值给全局指针、作为指针返回或发送到 channel。
go build -gcflags="-m" 输出里看到 &v escapes to heap 是什么信号
这表示编译器在当前行检测到对局部变量 v 取地址（&v），且该地址后续可能被函数外使用，因此必须将 v 分配到堆上。这不是警告，而是编译器已确定的分配决策。
常见触发点包括：
-
globalPtr = &v（赋值给包级指针变量） -
return &v（函数返回局部变量地址） ch （发送指针到 channel）-
closure := func() { _ = v }（闭包捕获并可能长期持有）
注意：&v escapes to heap 后如果紧接着出现 global escapes to heap 或 leaks to heap，说明该指针确实落到了全局可访问位置，生命周期已脱离函数控制。
为什么 global = &localVar 一定会导致逃逸，哪怕 global 是未导出变量
Go 编译器不做“运行时行为假设”。只要 global 是包级变量（哪怕 var global *int 是小写未导出），它就满足两个关键条件：
- 可在本包任意函数中读写（例如
GetGlobal()返回它） - 其值可能被跨 goroutine 使用（编译器无法静态排除）
因此，一旦执行 global = &localVar，编译器就必须保证 localVar 在 setGlobal 返回后仍有效——唯一安全的方式是堆分配。这不是保守策略，而是语言内存安全模型的强制要求。
试图用 unsafe.Pointer 或反射绕过此检查，会导致未定义行为，不推荐。
使用 OpenAI Codex CLI 处理编码任务。触发词：codex、code review、fix CI、refactor code、implement feature、coding agent、gpt-5-codex。Clawdbot 可将编码工作委托给 Codex CLI 作为子代理或直接工具。
如何确认某个局部变量是否被全局指针捕获
最直接方式是加冗余 -m 并禁用内联：
go build -gcflags="-m -m -l" main.go
重点关注三类输出：
-
&x escapes to heap（取地址操作本身逃逸） -
x escapes to heap（变量整体逃逸，不一定因取地址） -
global escapes to heap或leaks to heap（说明该指针已进入全局作用域）
若只看到第一行而没看到第三行，大概率是地址没真正“落”到全局变量里（比如只是临时传参、没赋值给包级变量）。可以配合 go tool compile -S 查看汇编中是否真有对包级符号的写入指令。
想保留全局访问语义但避免逃逸，有哪些可行替代方案
核心原则：不让局部变量地址物理上进入全局变量。可行路径包括：
- 改用值类型全局变量：
var global Config，然后用global = NewConfig()（前提是NewConfig()返回值而非指针） - 用 sync.Pool 管理复用对象，避免每次新建+逃逸
- 把需要“全局访问”的逻辑封装成方法，通过 receiver 传入所需数据，而非暴露指针
- 若必须用指针语义，考虑初始化阶段一次性分配（如
init()中 new 并赋值），避免在热路径中反复取地址
特别注意：用 make([]byte, 0, N) 初始化切片再复用，比在循环里反复 make([]byte, N) 更易逃逸——因为后者每次都是新局部变量，取地址即逃逸；前者只需一次堆分配，后续 append 复用底层数组。
