go中不能用普通字符串存敏感数据，因为string只读不可变，底层字节数组无法主动擦除，即使置空或置nil，原始数据仍留在堆内存中直至gc回收甚至被换出到swap，易被内存dump提取；必须用可写[]byte配合bytes.fill覆写、runtime.keepalive阻止优化、及时置nil，并规避cgo和系统调用泄漏风险。
为什么不能用普通字符串存敏感数据
Go 的 string 是只读且不可变的，底层指向底层数组，一旦分配就无法擦除——哪怕你把变量设为 "" 或 nil，原始字节仍留在堆上，直到 GC 回收（甚至可能被换出到 swap）。攻击者通过内存 dump 或 core dump 可轻易提取。这不是“会不会被回收”的问题，而是“何时、能否被真正覆写”的问题。
用 []byte + runtime.KeepAlive 控制存活期
真正可控的方案是手动管理字节切片，并在明确时间点覆写后主动通知 GC 不再持有引用：
- 用
make([]byte, n)分配可写内存，立即用rand.Read()填充密钥或解密结果 - 所有使用必须基于该切片，避免隐式转成
string（会复制且不可控） - 业务逻辑结束后，调用
bytes.Fill(secret, 0)覆写内存 - 紧接着用
runtime.KeepAlive(secret)防止编译器优化掉覆写操作（尤其在内联函数中易被删） - 最后将切片置为
nil，让 GC 后续回收——但覆写已在此前完成
示例关键片段：
secret := make([]byte, 32) _, _ = rand.Read(secret) // ... 使用 secret 进行 AES 加密 ... bytes.Fill(secret, 0) runtime.KeepAlive(secret) // 关键：阻止覆写被优化掉 secret = nil // 此时才解除引用
封装成带超时自动销毁的结构体
单纯手动覆写容易遗漏。更稳妥的是封装一个带生命周期控制的容器类型，支持定时自毁和显式销毁：
- 内部字段用
unsafe.Pointer指向[]byte底层数组，绕过 GC 对切片头的跟踪（需//go:build !race） - 启动一个
time.AfterFunc定时器，在指定秒数后自动覆写并释放 - 提供
Destroy()方法供提前触发，且保证幂等（重复调用不 panic） - 导出方法全部接收指针 receiver，避免值拷贝泄露副本
注意：unsafe 操作必须配 sync.Once 防止多次覆写，且销毁后所有访问应 panic 或返回 zero 值，不能静默失败。
别忽略 CGO 和系统调用带来的泄漏风险
即使 Go 层覆写了，若密钥曾传入 CGO 函数（如 OpenSSL）、syscall（如 unix.Syscall）或 C 字符串（C.CString），C 层内存不会被你的 bytes.Fill 触及。此时必须：
- 避免用
C.CString传递密钥；改用C.goBytes+ 手动C.free，并在 free 前覆写 - 调用 CGO 接口时，确认其文档是否承诺“不缓存输入缓冲区”；否则必须假设它已复制
- Linux 上可通过
mlock()锁住内存页防止 swap，但需 root 权限且要配对munlock()
最简实践：敏感数据全程不出 Go runtime，所有加解密用 crypto/aes 等纯 Go 包，彻底规避 CGO。
真正的“自销毁”不是靠 GC，而是靠你亲手覆写+及时解除引用+阻断所有隐式副本路径。任何环节漏掉——比如一次 string(secret) 转换、一次 CGO 透传、一个未执行的 KeepAlive——都会让销毁失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
