正确做法是只加密敏感字段值（如database.password），而非整个配置文件，以避免破坏viper、helm template等工具链兼容性；加密采用aes-gcm（32字节密钥、12字节随机nonce），base64编码后加enc[aes-gcm]::前缀存入明文配置，加载后通过viper.allsettings()递归解密并覆写map。
只加密敏感字段值，别碰整个配置文件
整文件加密会让 viper、helm template、jq 全部失效，CI/CD 脚本要额外加解密步骤，还容易把密文当明文提交。真实项目中唯一可落地的做法是：只对 database.password、redis.auth、api.token 这类键路径的值加密，其余结构保持明文 YAML/TOML/JSON。
加密后字段示例：database: password: "ENC[AES-GCM]::YmFzZTY0LWVuY29kZWQtc3RyaW5n"
- 前缀
ENC[AES-GCM]::是解密时快速识别的标记，非加密字段直接跳过 - 密文必须是 base64 编码的单行字符串，不能直接存二进制字节（YAML 解析会失败）
- 加密逻辑不侵入配置加载流程，只作用于字段值，不影响
viper.Unmarshal类型推导
用 crypto/aes + cipher.NewGCM 实现字段级加解密
AES-GCM 是 Go 标准库原生支持、已通过 FIPS 验证的方案，同时提供机密性与完整性校验。手搓 CBC+HMAC 容易出错，不推荐。
- 密钥必须为 32 字节（AES-256），绝不能写成
[]byte("mykey")；生产环境建议用pbkdf2.Key派生，带随机 salt 和 ≥100000 轮迭代 - nonce 固定 12 字节，每次加密都调用
crypto/rand.Read(nonce[:])生成新值，绝不复用 - 加密输出为
nonce + ciphertext + auth tag（共 12 + N + 16 字节），再经base64.StdEncoding.EncodeToString编码 - 解密失败时
aesgcm.Open返回cipher.ErrAuthentication或cipher.ErrInvalidLength，必须显式判断err != nil，不能靠返回切片长度判断
解密时机必须在 viper.AllSettings() 之后
不能在 os.ReadFile 后立刻解密原始字节流，也不能 hook viper.ReadInConfig 的文件读取器——这会绕过字段定位逻辑，破坏类型推导，且无法精准匹配嵌套路径。
- 正确流程：先调用
viper.ReadInConfig()完成加载 → 再调用viper.AllSettings()获取顶层map[string]interface{} - 递归遍历该 map，按预设敏感路径列表（如
["database.password", "redis.auth"]）匹配键路径 - 对匹配到的字符串值，检查是否含
ENC[AES-GCM]::前缀，再提取 base64 内容解密 - 解密成功后，用
viper.Set或直接覆写 map 中对应位置的值；若需更高安全等级，业务使用后立即调用bytes.Fill清空明文切片
密钥管理最容易被跳过的三个细节
密钥本身的安全决定了整个加密方案是否有效，但工程落地中最常被忽略的是：
- 密钥绝不能硬编码，也不能随配置文件一起 Git 提交；开发环境可用环境变量
CONFIG_KEY，生产环境必须对接 KMS（如 HashiCorp Vault、AWS KMS）或 etcd 的 ACL 控制 - nonce 必须每次随机生成，不能用时间戳、计数器或固定值——GCM 对 nonce 复用极其敏感，复用即导致密钥泄露
- 解密后的明文密码留在内存里，若服务长期运行且无主动清零，可能被内存 dump 或日志意外打印；
bytes.Fill不是可选项，是必须项
真正安全的边界不在算法多强，而在密钥怎么来、nonce 怎么生、明文怎么走。这三个点漏掉任何一个，加密就形同虚设。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
