数据库密码明文写在config.yaml中极其危险，等同于将钥匙挂在门把手上，一旦git提交、ci日志、容器镜像或运维快照泄露，数据库即完全暴露；且明文密码会残留于/proc//environ和ps输出中，必须杜绝原始形态进入运行时内存。
数据库密码明文写在 config.yaml 里有多危险
直接把 password: mydb123 写进 YAML 配置文件，等于把钥匙挂在门把手上。Git 提交、CI 日志、运维快照、容器镜像层——任何环节泄露，数据库就裸奔。更糟的是，Go 进程启动后若用 os.Getenv("DB_PASSWORD") 加载，该值会完整出现在 /proc/<pid>/environ</pid> 中，ps auxf 也能间接暴露（尤其当环境变量名含敏感词时）。
真正安全的起点不是“怎么加密”，而是“密码绝不以原始形态进入运行时内存”。所以所有方案都绕不开两个前提：配置文件权限必须设为 600，HTTPS 必须启用（防止 Basic Auth 凭据被截获）。
用 viper + AES 解密配置项（推荐给生产环境）
viper 本身不带解密能力，但可配合 golang.org/x/crypto/aes 和 golang.org/x/crypto/cipher 自行实现。关键不是“加了密”，而是密钥和密文分离：
- 密钥通过环境变量或 KMS 注入（如
AES_KEY=32-byte-hex-string），启动后立即调用os.Unsetenv("AES_KEY") - 配置文件中只存密文：
password: "U2FsdGVkX1+abc123..." - viper 读取后，用 AES-GCM 模式解密，失败则 panic，不返回空字符串或默认值
示例片段（非完整中间件）：
func decryptPassword(enc string) (string, error) {
key := os.Getenv("AES_KEY")
os.Unsetenv("AES_KEY") // 立即清除
block, _ := aes.NewCipher([]byte(key))
aesgcm, _ := cipher.NewGCM(block)
ciphertext, _ := base64.StdEncoding.DecodeString(enc)
plaintext, err := aesgcm.Open(nil, ciphertext[:12], ciphertext[12:], nil)
return string(plaintext), err
}
为什么不用 jasypt 或 druid 那套方案
Java 生态的 jasypt 或 druid 加密依赖 Spring Boot 的 PropertySource 机制和自动解密生命周期，Gin 没有等价物。硬搬过来要自己实现配置重载、密钥管理、失败 fallback —— 成本远超收益。Go 生态更倾向“小而专”：用 viper 做配置加载，用 crypto/aes 做解密，用 os.Unsetenv 清理痕迹，链条短、可控性强。
另一个现实约束：gorm.Open() 的 DSN 字符串必须在 init() 或 main() 阶段完全构造好，没有“延迟解密”的钩子入口。所以解密动作必须发生在 DSN 组装之前，不能塞在 GORM 的 BeforeConnect 钩子里。
bcrypt 不适合加密数据库密码
看到资料里提 bcrypt 就容易混淆——它专为**用户密码哈希**设计，特点是故意慢（防爆破）、带盐、不可逆。但数据库连接密码需要的是**快速加解密**，且必须能还原明文（否则 GORM 连不上）。拿 bcrypt.GenerateFromPassword 去处理 DB 密码，等于把钥匙熔掉再铸成另一把锁，根本打不开门。
真正该用 bcrypt 的地方只有一个：用户注册时对 User.Password 字段哈希存储；而数据库连接凭据，必须用 AES 或类似对称算法。
最易被忽略的一点：解密后的数据库密码一旦进入 gorm.Open() 的 DSN 字符串，就会常驻进程内存，直到程序退出。无法主动“擦除”——所以降低风险的唯一办法，是缩短其暴露窗口：解密 → 连接 → 启动服务，三步之间不要做任何阻塞操作，更不要把它塞进全局变量或 context 里长期持有。
