Go 1.26 实验包 runtime/secret：函数返回时清空寄存器与栈，堆要等 GC
Go 1.26 新增实验包 runtime/secret，处理的正是密码学代码里一个长期被忽略的残留风险：密钥材料用完以后，仍会留在寄存器、栈和堆上。Go 的 GC 只负责回收内存，不负责擦除内容。这个包把「运行一段处理机密的代码」变成一个语义明确的单元，让前向保密（forward secrecy）更容易保证。参考资料为 Go 1.26 release notes 与官方发布博客。
它解决什么问题
处理私钥、握手临时密钥、解密后明文的代码，数据会在短时间内经过寄存器、函数栈帧和堆对象。函数返回、对象变成垃圾之后，内存内容并不会自动归零；堆内存页可能被后续分配复用，也可能随进程快照、core dump 或 swap 离开进程地址空间。
Go 运行时此前没有为此提供任何保证，runtime/secret 要补上的就是这段空白。
启用：构建期 opt-in
这个包默认不启用，需要在构建时打开 experiment：
GOEXPERIMENT=runtimesecret go build ./...
不主动使用这个包时，不会产生额外运行时开销。
用法：在 secret 模式下运行函数
这个包的入口语义是「让一个函数在 secret 模式下运行」：把需要接触机密的逻辑包成一个函数传进去，执行结束时由运行时接管清理。具体的函数名与签名以 runtime/secret 包文档为准，release notes 层面只承诺这一层语义。
// 示意结构，函数名与签名以 runtime/secret 包文档为准
secret.Do(func() {
// 解密、签名、密钥协商等接触明文的逻辑
})
业务逻辑本身不需要改写，需要改的是边界：哪一段计算接触明文密钥，就把哪一段计算放进这个函数。
语义边界：寄存器和栈立即清除，堆等 GC
官方博客给出的保证分为两层：
- 函数返回时，函数用过的寄存器和栈会被立即清零，这一步是同步的、确定的；
- 函数产生的堆分配不会立即清零，而是等垃圾回收器判定该对象不可达之后再擦除。
因此，「函数一返回，堆上的明文就立刻消失」是做不到的。这是最容易与直觉冲突的一点：如果代码把密钥拷进逃逸到堆的切片或结构体，它的清空时机就取决于 GC 什么时候运行、可达性判定什么时候成立。如果希望密钥的生命周期完全落在同步擦除的范围内，就需要关注逃逸分析，尽量让敏感数据留在栈上。
平台限制
目前仅支持 Linux 的 amd64 和 arm64。在其他平台上构建或运行时，不会获得这套保证；交叉编译到 darwin、windows 或这两个架构之外的平台时，需要按普通代码处理。
何时值得用
值得用的场景：
- 长期私钥的加载与使用过程，例如 TLS 证书私钥、签名密钥；
- 握手阶段的临时密钥。Go 1.26 同时新增
crypto/hpke（RFC 9180，含后量子混合 KEM）、crypto/mlkem相关加速，并让crypto/tls默认启用 SecP256r1MLKEM768 等混合密钥交换，这些场景里临时密钥的生成与销毁更频繁，更需要注意生命周期管理； - 解密之后的明文缓冲区。
不建议用的场景：
- 普通业务代码。没有需要擦除的机密，套上这一层只会增加构建约束和逃逸分析负担；
- 需要靠日志、panic 栈、dump 排查问题的路径。secret 模式的设计前提就是「这段内容不应被观察」，把它用在需要可观测性的地方，两者会互相冲突。
与显式清零的对比
常见做法是拿到密钥后手写 for i := range buf { buf[i] = 0 }，或者使用 crypto/subtle 一类的辅助函数。这有两个问题：
- Go 编译器可能把这次写入当作死存储（dead store）优化掉，尤其是对之后不再被读取的局部变量；
- 即使写入保留了下来，它也只覆盖你显式指定的那块内存。寄存器里的副本、栈上的临时值、调用链中间产生的中间量，都不在覆盖范围内。
runtime/secret 是在运行时层面处理这件事，覆盖寄存器与栈，而这正是不容易通过手写代码补上的部分；代价是它覆盖不了的堆，仍然要等 GC。
实验状态
runtime/secret 在 Go 1.26 中标记为实验 API，需要显式 opt-in 才能使用。官方的说法是：实现本身已经可以用于生产，标为实验主要是为了收集 API 反馈，尤其是「把它做成一个新包」这个选择是否合适。使用方需要自行承担后续 API 变更的成本，并在构建脚本里固定保留 GOEXPERIMENT=runtimesecret。该包的目标是在未来版本中转正。