Go 1.26 runtime/secret 如何擦除敏感栈数据：secret.Do 与指针逃逸边界

处理私钥、会话密钥或临时口令时，开发者通常只想到“用完把切片清零”。Go 1.26 提供的实验包 runtime/secret 把范围扩大到调用链里的寄存器和栈临时值：在 Linux amd64 或 arm64 上，用 secret.Do 包住敏感计算，函数返回后由运行时清理这些临时数据。

runtime/secret 不是“所有内存立即归零”的开关。它适合缩短敏感临时值的生命周期；堆对象仍要先丢掉全部引用，结果若要带出作用域则应复制到调用方创建的对象。

先用 GOEXPERIMENT 打开 runtime/secret

这是 Go 1.26 的实验能力，不是默认可导入的稳定包。项目可以把构建开关放在实验分支或专用构建任务里，先验证运行环境：

GOEXPERIMENT=runtimesecret go test ./...
GOEXPERIMENT=runtimesecret go run .

代码侧的最小调用只需要导入 runtime/secret，把处理敏感值的闭包交给 secret.Do：

package main

import "runtime/secret"

func verifyKey(input []byte) bool {
    valid := false
    secret.Do(func() {
        valid = checkMAC(input)
    })
    return valid
}

这里的 valid 是调用方已经拥有的布尔值，闭包只负责计算结果。不要把密钥对象、临时明文或中间缓冲区塞进全局变量；全局变量不属于 secret.Do 的保护范围。

secret.Do 清理的对象，和它不负责的对象

从实现语义看，secret.Do 先进入 secret 模式，执行闭包，再调用 eraseSecrets，最后退出模式。闭包内部调用的函数也属于这条调用链，因此中间函数产生的栈临时值不会因为跨了一层函数就自动失去保护。

secret.Enabled 可以用来确认当前 goroutine 是否处在 secret 模式。它适合做调试断言或测试辅助，不应该成为业务安全判断的唯一依据：

func checkMAC(input []byte) bool {
    if !secret.Enabled() {
        return false
    }
    return constantTimeCheck(input)
}

需要特别区分三类数据：

返回值为什么要复制到调用方分配的对象

官方文档特别提醒：如果闭包需要返回一个不应被清理的结果，应该把结果复制到由调用方创建的分配中。原因很直接：在 secret.Do 内扩容切片或创建 map，内存属于这段敏感调用的分配链，离开闭包后可能进入清理范围。

func derivePublicKey(input []byte) []byte {
    output := make([]byte, publicKeySize)
    secret.Do(func() {
        temporary := deriveTemporary(input)
        copy(output, temporary)
    })
    return output
}

上面的 output 在调用方创建，闭包只做返回值复制；temporary 仍然留在敏感调用内部。这个模式不能保护调用方之后主动保存的敏感数据，也不能替代密码学库提供的密钥生命周期管理。

panic、Goexit 与 goroutine 边界要单独验收

secret.Do 即使闭包 panic，也会先完成栈和寄存器清理，再让 panic 从 Do 这一层重新出现。测试不要只覆盖正常返回，还要验证敏感临时值没有通过 panic 值被无意带出。

在闭包里启动的 goroutine 会像被另一层 secret.Do 包住一样运行，但这不等于可以随意把敏感数据传给后台任务。通道、日志、错误包装和缓存都可能把引用带出原本的生命周期。

runtime.Goexit 是另一条边界：上层 defer 可能让擦除延迟。涉及请求取消或测试退出时，先确认是否真的需要在 secret 模式里调用 Goexit，不要把它当作普通 return 使用。

平台支持和性能代价不能省略

Go 1.26 文档给出的完整支持范围是 Linux amd64 与 Linux arm64。其他平台上，secret.Do 会直接调用闭包，因此代码仍能运行，但不能把它宣传成同等的敏感数据擦除保证。跨平台项目应把实验开关、目标平台和安全说明一起写进发布清单。

在闭包里频繁扩容切片、插入 map 或制造大量临时堆对象，会增加垃圾回收的清扫工作和跟踪成本。更稳妥的做法是缩小 secret.Do 范围，提前准备调用方输出缓冲区，把需要返回的结果复制出去。

上线前用四项检查确认边界

1. 构建：明确哪些构建任务设置了 GOEXPERIMENT=runtimesecret，并记录目标 GOOS/GOARCH。
2. 引用：检查密钥、明文和临时缓冲区没有写入全局变量、日志、错误值或长期缓存。
3. 分配：检查闭包里的切片扩容、map 插入和返回对象，必要时改成调用方预分配后复制。
4. 异常：覆盖正常返回、panic、goroutine 和取消路径，并确认错误包装没有携带敏感对象。

相关问题

runtime/secret 能替代手动清零吗？

不能完全替代。它主要处理调用链里的寄存器、栈和符合条件的堆临时值；业务自己持有的切片、全局状态和日志仍要按生命周期管理。

在 macOS 或 Windows 上调用 secret.Do 安全吗？

代码可以运行，但当前完整擦除支持只覆盖 Linux amd64 和 Linux arm64。其他平台会直接执行闭包，不能据此承诺相同的清理效果。

为什么结果不能直接从 secret.Do 返回？

闭包内创建的结果可能属于敏感调用的堆分配。把结果复制到调用方预先创建的对象，能更清楚地划分需要保留和可以清理的内存。

小结

runtime/secret 的价值在于把“敏感计算结束后清理临时值”交给运行时协助完成，但它的边界同样明确：实验开关要显式启用，堆对象受 GC 时机影响，全局变量不受保护，平台支持也有限。把敏感调用缩在短小的 secret.Do 闭包里，再用调用方对象承接必要结果，才是容易审查和回归的落地方式。