runtime/secret 为什么不能替代完整的密钥管理系统

runtime/secret 不能替代完整的密钥管理系统，因为它只处理应用进程里的一个局部问题：尽快擦除密码学代码调用树留下的临时内存。密钥从哪里生成、保存在哪里、谁能取用、如何轮换、怎样审计、何时撤销和销毁，都不在这个包的职责范围内。

官方文档：https://pkg.go.dev/runtime/secret

它解决的是“用完后还留在内存里”

Go 官方把 runtime/secret 定义为实验包。它通过 secret.Do(func()) 包住一棵调用树，目标是让这段代码使用过的寄存器和栈在返回前被擦除；调用树产生的堆分配，则要等对象不可达并被垃圾收集器发现后再擦除。这个设计主要服务于前向保密等场景：即使进程稍后被读取，也尽量少留下已经用过的临时秘密。

这是一种运行时内存卫生能力。它既不创建密钥身份，也不知道一个字节切片代表 API 密钥、TLS 私钥还是数据密钥，更不会替应用决定谁有权使用它。

secret.Do 的保护边界没有覆盖完整秘密生命周期

当前文档列出的边界很具体，理解这些限制比只记住“会清零内存”更重要。

目前官方文档只声明支持 linux/amd64 与 linux/arm64。包仍是实验性的，不受 Go 1 兼容承诺保护，并且只有构建时启用 GOEXPERIMENT=runtimesecret 才存在。若部署平台不匹配，secret.Do 不会提供同样的擦除能力。

最小用法：把密码学临时对象限制在调用树内

下面的例子把 HMAC 计算包进 secret.Do。输出数组由调用方预先创建，因此它可以安全返回；哈希对象和 Sum 产生的临时切片位于受保护调用树中。需要特别注意：传入的 key 本来就由调用方持有，secret.Do 不会替调用方删除那个原始副本。

package secretmac

import (
    "crypto/hmac"
    "crypto/sha256"
    "runtime/secret"
)

func Sum(key, message []byte) [sha256.Size]byte {
    // 结果不属于秘密，由调用方预先分配，避免把受保护区内的对象直接返回。
    var result [sha256.Size]byte

    secret.Do(func() {
        // 哈希状态与临时摘要留在 secret.Do 的调用树中。
        mac := hmac.New(sha256.New, key)
        _, _ = mac.Write(message)
        copy(result[:], mac.Sum(nil))
    })

    return result
}

构建时必须显式开启实验。生产发布还应固定工具链版本，并把实验开关纳入可复现构建配置。

# runtime/secret 只有在构建时启用实验开关才可导入
GOEXPERIMENT=runtimesecret go build ./cmd/service

# 在同一构建环境运行测试，避免开发机和发布机开关不一致
GOEXPERIMENT=runtimesecret go test ./...

这段代码验证的是 API 形状，不代表密钥管理已经完成。密钥如果来自环境变量、配置文件或长期缓存，那些来源和副本仍然要独立治理。

完整密钥管理系统还要解决什么

密钥管理的范围远大于进程内擦除。NIST SP 800-57 把密钥保护、管理功能、策略、恢复、传输、授权、审计等都纳入密钥管理问题。云 KMS 的公开能力也体现了同样的边界：密钥有身份和版本，访问由 IAM 或密钥策略约束，轮换有计划与记录，调用能进入审计日志。

因此，把 runtime/secret 当作 KMS 的替代品，就像把“离开房间时擦掉白板”当成“整座档案馆的门禁、编号、借阅和销毁制度”。白板擦除很有价值，但它只解决暴露面中的一段。

推荐架构：KMS 管钥，应用只短暂使用

更稳妥的架构是让应用只持有密钥引用、密文数据密钥或短期凭据。真正的根密钥由 KMS/HSM 或组织认可的密钥服务托管，应用凭工作负载身份请求解密、签名或解包。必须进入进程的明文数据密钥，则尽量在 secret.Do 边界内完成使用，不把它写进全局变量、日志、错误消息或长期缓存。

• 外部生命周期：生成、托管、授权、轮换、版本、审计、撤销和销毁由密钥服务负责。
• 进程内边界：明文材料只在最小调用树中出现，计算完成后不再保留引用。
• 非秘密结果：摘要、签名或密文由调用方预先分配并接收，避免返回秘密对象。
• 失败路径：错误信息不携带明文密钥；panic 值也不能引用受保护区里的敏感分配。
• 平台门禁：构建与部署阶段明确检查实验开关和受支持的 Linux 架构。

三个反例说明为什么单靠它不够

把环境变量读进全局切片

即使后续计算放进 secret.Do，全局切片里的原始密钥仍然存在。包文档明确指出，对全局变量的写入不在保护范围内。

在 Do 内大量追加切片和写 map

这些操作可能不断扩容并产生新堆分配。官方提醒，跟踪并擦除这些分配会增加 GC sweep 成本；扩容时可能需要擦除整个新分配，而不只是其中的秘密部分。

没有身份、轮换和审计就直接上线

内存擦除无法回答“谁在什么时间使用了哪一版密钥”。一旦密钥泄露，也没有撤销、换版和追踪机制。这个缺口只能由密钥管理流程补齐。

采用前的判断清单

• 部署目标是否是官方支持的 linux/amd64 或 linux/arm64？
• 团队是否接受实验 API 不受 Go 1 兼容承诺保护的风险？
• 秘密是否只在 Do 调用树中短暂出现，还是早已存在于全局、环境变量或长期缓存？
• 是否已经有可信的密钥生成、托管、身份授权、轮换、审计和撤销机制？
• 是否限制了受保护区内的堆分配，并压测过 GC 与延迟影响？
• 错误、日志、panic 值和指标标签是否可能带出秘密材料？

常见问题

runtime/secret 会自动清除传入的 key 切片吗？

它会处理调用树使用的临时存储，但调用方原本持有的切片和其他副本不因此消失。输入密钥的来源、持有时间和清理仍由应用负责。

Do 返回时堆上的秘密一定已经清零吗？

不一定。堆分配要等对象不再可达，并由垃圾收集器发现后才会擦除，具体时间受 GC 调度影响。

在 macOS 或 Windows 上启用实验能得到同样保护吗？

当前官方文档只声明支持 Linux 的 amd64 和 arm64。不支持的平台上 Do 只是调用传入函数，不能假设存在同等擦除效果。

有了 HSM，还需要 runtime/secret 吗？

取决于明文密钥是否进入应用进程。如果密码学操作完全留在 HSM 内，进程内明文暴露较少；如果数据密钥会进入 Go 内存，runtime/secret 可作为额外的内存卫生层。

什么时候不适合马上使用？

部署平台不受支持、无法固定实验构建、秘密长期存在于全局状态，或受保护区内分配压力很大时，应先修正架构并做性能评估。

把它放在正确的一层

runtime/secret 的价值很明确：缩短密码学临时数据在 Go 进程中的残留时间。但它不是密钥身份、权限策略、版本历史和审计记录的承载者。将它放在 KMS/HSM 之后、密码学使用点附近，才能同时覆盖“密钥怎么被管理”和“密钥进入内存后怎么少留痕”这两个不同问题。