明文写死数据库密码极不安全，因二进制中字符串易被strings提取，配置文件泄露（Git/日志/镜像）即导致凭据裸奔；base64非加密、硬编码密钥无效、本地.key文件权限风险高；须用AES-GCM配合动态密钥（KMS或严格权限文件）、12字节随机nonce与密文拼接存储，并通过YAML自定义Unmarshal实现透明解密。
为什么不能直接把 config.yaml 里的数据库密码明文写死
因为一旦二进制被反编译（strings ./myapp | grep password 就能捞出关键字段），或配置文件意外泄露（如 Git 提交、日志打印、容器镜像层残留），攻击者就能直接连库。Go 编译后的二进制里字符串常量极难抹除，明文配置 = 等于裸奔。
常见错误现象：panic: failed to connect: pq: password authentication failed for user "admin" —— 实际不是密码错，是解密失败后传了空串过去。
- 别用 base64 当加密：它只是编码，
base64 -d一解就露馅 - 别在代码里硬编码加密密钥：密钥和密文一起打包进二进制，毫无意义
- 别把密钥存在同目录的
.key文件里：权限没设好，ls -l一眼可见
用 aes-gcm 解密配置项前必须校验密钥来源
GCM 模式本身安全，但密钥若来自环境变量或文件，就得防篡改和越权读取。生产环境推荐用 os.Geteuid() == 0 + stat 校验密钥文件权限是否为 0400；开发环境可用 KMS（如 AWS KMS 或 HashiCorp Vault）动态获取密钥，避免本地落盘。
示例判断逻辑：
立即学习“go语言免费学习笔记（深入）”；
fi, err := os.Stat("/etc/myapp/key.aes")
if err != nil || fi.Mode().Perm() != 0400 {
log.Fatal("key file permission unsafe or missing")
}
- 密钥长度必须为 16 或 32 字节（对应 AES-128 / AES-256），
len(key) != 32会导致cipher.NewGCMpanic - 每次加密需生成新 nonce（12 字节），但解密时必须用加密时那个——所以 nonce 要和密文一起存，比如 YAML 里写成
password: "nonce:xxx|ciphertext:yyy" - 不要自己拼接 IV 和密文：GCM 的
Seal()已包含 nonce 前缀，直接用Open()解即可
YAML 解析时如何透明注入解密逻辑
Go 的 gopkg.in/yaml.v3 支持自定义 UnmarshalYAML 方法，这是最干净的接入点——不用改业务结构体定义，也不用预处理整个文件。
比如给 DBConfig 加一层封装：
type EncryptedString struct {
raw string
}
func (e *EncryptedString) UnmarshalYAML(value *yaml.Node) error {
if err := value.Decode(&e.raw); err != nil {
return err
}
decrypted, err := decryptAESGCM([]byte(e.raw))
if err != nil {
return fmt.Errorf("decrypt failed: %w", err)
}
e.raw = string(decrypted)
return nil
}
func (e *EncryptedString) String() string { return e.raw }
- 字段类型从
string换成*EncryptedString，YAML 里仍写password: "aes:YmFk..."，解密对上层完全透明 - 如果某些字段可选加密（如测试环境用明文），可在
UnmarshalYAML里先检查前缀是否为"aes:"，否则直赋值 - 注意：该方法不支持嵌套结构体自动递归解密，每个需解密字段都得单独包装
go build 后密钥管理的三个落地约束
二进制发布后，密钥不能随包分发，也不能靠人肉运维去每台机器放一遍。必须有自动化兜底机制。
- 启动时优先查
VAULT_ADDR+VAULT_TOKEN：存在则调v1/transit/decrypt；失败再 fallback 到本地文件（仅限 dev/staging） - 本地密钥文件路径必须绝对且不可配置（如固定
/etc/secrets/app.key），防止通过命令行参数绕过校验 - 加个启动检查：运行
ldd ./myapp | grep crypto确保没意外链接到非标准 crypto 库（某些 CGO 依赖会破坏 GCM 实现一致性）
最易被忽略的一点：加密配置只解决静态存储风险，运行时内存中的明文密码仍可能被 gcore 或 /proc/PID/mem 读取——真高敏场景得配合内存锁定（syscall.Mlock）和及时覆写，但这会增加维护成本，多数服务其实只需守住磁盘和网络边界就够了。
