cipher.NewGCM安全使用需严守三原则：密钥长度必须为16/24/32字节且须经hex/base64解码校验；nonce每次加密须全新随机生成12字节并原样拼接密文前；GCM密文含12字节nonce+密文+16字节认证tag，解密时须完整读取并校验。
直接用 cipher.NewGCM 加密敏感数据，只要密钥长度对、nonce 不重复、不复用切片，基本不会翻车；但绝大多数 panic 和静默解密失败，都卡在这三步上。
为什么 cipher.NewGCM 一调就 panic: "invalid key size"
不是密钥“不够强”，而是 Go 对字节长度抠得极严：aes.NewCipher 只接受 []byte 类型，且长度必须是 16 / 24 / 32 —— 一个都不能多，一个都不能少。
- 字符串字面量如
"my-secret-32-byte-key-12345678"看似 32 字符，但 UTF-8 编码下中文或 emoji 会占多个字节，实际长度可能变成 34 或 36 - 用
md5.Sum或sha256.Sum256直接转[]byte也不行：它们返回的是带固定底层数组的结构体，强制转换后类型不匹配，运行时仍报错 - 正确做法：从环境变量或配置读入 hex 或 base64 编码的密钥，再用
hex.DecodeString或base64.StdEncoding.DecodeString解码，最后严格校验长度
如何安全生成和复用 nonce
nonce 不是 IV，它不要求“不可预测”，只要求“全局唯一（per key）”；重复使用同一 key + nonce 组合，攻击者能直接恢复密钥流——这不是理论风险，是标准库明确警告的硬伤。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐方式：用
crypto/rand.Read(nonce)生成 12 字节随机值（GCM 最佳实践长度），每次加密都make([]byte, gcm.NonceSize())新分配，绝不复用已有 slice - 别把
nonce当作可压缩字段：存文件时直接拼在密文前，比如append(nonce, ciphertext...)；传输时也保持原样，别加 length prefix、别用 binary.Write 包装 - 如果需要可还原
nonce（例如基于时间戳或计数器），必须保证：每个密钥独占一个单调递增计数器，且初始值足够大、不重叠
gcm.Seal 返回的密文为什么比原文长？解密时怎么拆？
多出来的 16 字节是 GCM 认证标签（authentication tag），不是冗余数据，而是完整性校验的必需部分。没有它，gcm.Open 就无法判断密文是否被篡改，等于退化成不带认证的裸加密。
立即学习“go语言免费学习笔记（深入）”；
- 加密输出结构固定为：
[12-byte nonce][ciphertext][16-byte tag]（注意：tag 是gcm.Seal自动追加在末尾的，不是你手动拼的） - 解密时先用
io.ReadFull读前 12 字节到nonce切片，再把剩余字节全传给gcm.Open；别用Read+len判断，容易读不全 - 常见错误：
gcm.Open返回nil而非 error（比如 tag 校验失败），或静默返回空切片——这说明 nonce 长度不对、密钥错、或密文被截断，不是“没写好逻辑”，是输入结构本身已损坏
真正难的不是写对那几行 Seal/Open，而是让 nonce 在整个生命周期里不重复、不混淆、不被序列化污染；密钥可以派生，nonce 必须每次新鲜生成并原样传递——这点一旦漏掉，所有加密都形同虚设。
