应仅加密敏感字段值而非整个配置文件，使用aes-gcm对database.password等指定路径字段加密，密文base64编码并加enc[aes-gcm]::前缀，解密在配置加载完成后递归处理内存结构。
只加密敏感字段，别碰整个配置文件
整文件加密看似一劳永逸，实际会让 viper、helm template、jq 全部失效，连 git diff 都看不出哪改了密码。真正可落地的做法是：保留 TOML/YAML/JSON 明文结构，仅对 database.password、api.token 这类字段值做加解密。
- 解析配置为
map[string]interface{}（用mapstructure.Decode），递归遍历键名匹配预设敏感路径列表 - 对匹配到的字符串值调用
aesgcm.Open解密，还原后塞回原位置 - 加密时也只取原始明文字符串，加密后写回对应字段，其他字段完全不动
- 注意
viper的Set不支持嵌套路径写入，得先Get出父 map 再手动赋值
用 AES-GCM 加密字段值，别手搓 CBC+HMAC
字段级加密不是“小文件”，但依然要防篡改。AES-CBC 本身不带完整性校验，单独加 HMAC 容易顺序错乱（比如先解密再验签），而 cipher.NewGCM 一步到位，标准库已通过 FIPS 验证路径，够用且安全。
- 密钥必须是 32 字节（AES-256），不能用
[]byte("mypassword")硬编码；生产环境用pbkdf2.Key派生，带随机salt和 ≥100000 轮迭代 - nonce 固定用 12 字节：
make([]byte, aesgcm.NonceSize())，每次加密都rand.Read新生成 - 加密后结构是
nonce + ciphertext + tag（tag 固定 16 字节），存进 YAML 字段时建议 base64 编码成单行字符串 - 解密失败时，
aesgcm.Open返回cipher.ErrInvalidLength或cipher.ErrAuthentication，不是nil就代表成功——乱密钥也可能解出字节流，只是内容错乱
解密时机放在配置加载完成之后，而非读文件时
很多人想在 os.ReadFile 后立刻解密整个字节流，这会破坏格式可读性，也绕不开字段定位逻辑。正确做法是让配置解析流程走完，所有字段加载进内存结构后再批量解密敏感值。
- 不要在
viper.SetConfigFile前改原始文件内容；也不要在viper.ReadInConfig里 hook 文件读取器 - 推荐流程：
ReadInConfig→viper.AllSettings()得到顶层 map → 递归处理敏感 key → 所有解密完成后再启动业务逻辑 - 若用
mapstructure.Decode到 struct，需确保目标字段是*string或自定义类型实现UnmarshalText，才能在反序列化阶段介入解密 - 注意：解密后的明文密码留在内存里，如需更高安全等级，可用
bytes.Fill在使用后立即清空切片
base64 编码密文字符串，别直接存二进制
YAML/TOML/JSON 都是文本格式，直接把 []byte{0x1a, 0xff, ...} 写进去会导致解析失败或截断。密文必须编码，且编码方式要固定、无歧义。
- 一律用
base64.StdEncoding.EncodeToString，别用URLEncoding（YAML 里可能被误解析为锚点） - 存进配置时加个标识前缀，比如
ENC[AES-GCM]::Y2lwaGVyLmRhdGEuZ29lcw==，方便后续识别和切换算法 - 解密时先按
::分割，检查前缀是否匹配，再 base64 解码——避免把普通字符串误当密文解，导致 panic - 别在配置里存
salt或nonce的原始二进制；它们已包含在 base64 字符串里，解码后按固定偏移（前 12 字节）提取即可
最容易被跳过的点是：密钥派生参数（salt、迭代次数、哈希函数）和 nonce 长度必须固化在代码里，不能靠文档约定。换一个部署环境或升级依赖，只要其中一项不一致，解密就静默失败，连错误提示都不给你。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
