Go框架配置加密需分场景：运行时解密用环境变量+外部密钥管理，静态配置如JWT secret须强制校验长度与轮换；crypto/aes要求密钥严格为16/24/32字节，IV须随机生成且不可复用，go-zero的Sensitive接口仅在Infov/Errorv等带字段日志中触发脱敏。
Go 框架中配置加密不是“配个密钥就行”，核心在于区分场景：运行时解密（如数据库密码）必须用环境变量 + 外部密钥管理，而静态配置项（如 JWT secret）可内嵌但需强制校验长度与轮换机制。
crypto/aes 使用前必须校验密钥长度和 IV 初始化
AES 是块密码，NewCipher 只接受 16、24 或 32 字节密钥，传入 "mykey" 这类短字符串会静默返回 nil，后续调用 Encrypt 必 panic。常见错误还包括：
-
dst切片未预分配容量，直接var dst []byte导致写入越界 - 忽略 IV（初始向量）的随机性，复用同一 IV 会使相同明文生成相同密文
- 未使用 GCM 模式就自行拼接认证标签，失去完整性保护
正确做法是用 crypto/rand.Read 生成 12 字节 IV，并确保密钥从环境变量或密钥服务加载后做长度断言：
key := []byte(os.Getenv("AES_KEY"))
if len(key) != 32 {
log.Fatal("AES key must be exactly 32 bytes")
}
go-zero 的 Sensitive 接口不自动触发，需配合日志输出路径
定义了 MaskSensitive() 方法的结构体，只有在通过 logx.Infov、Errorv 等带字段参数的日志函数输出时才会被调用。直接 logx.Info(user) 不会触发脱敏。
立即学习“go语言免费学习笔记（深入）”；
- 字段名必须完全匹配（如
Password不能写成password） - 若结构体嵌套多层，只有一级字段会被检测，
User.Profile.Password不会自动脱敏 - 非结构体类型（如 map[string]string）不会走该接口，需手动过滤
实际调试时可加一行 logx.Infov(map[string]any{"user": user}) 验证是否生效。
环境变量不是万能保险，需配合启动时校验与最小权限
把 DB_PASSWORD 放进 os.Getenv 只是第一步。真正容易出问题的是部署环节：
- Docker 容器未用
--env-file或env_file:加载，导致变量为空 - Kubernetes Secret 挂载为文件而非环境变量，但代码仍调用
Getenv - 本地开发用
.env，但 CI/CD 流水线没同步该文件，测试环境跑不通
建议在 main() 开头集中校验关键变量：
for _, env := range []string{"DB_PASSWORD", "JWT_SECRET", "AES_KEY"} {
if os.Getenv(env) == "" {
log.Fatalf("%s is required", env)
}
}
JWT 密钥轮换不能只靠重启服务
go-zero 的 WithJwtTransition 允许同时支持新旧密钥，但前提是旧密钥仍保留在内存中。如果服务滚动更新时旧 Pod 已销毁，而新 Token 尚未全量分发，就会出现“部分用户登出”现象。
- 过渡期至少覆盖 JWT 的最长有效期（如 24h Token 就要维持 24h 双密钥）
- 密钥本身不应硬编码，应从 Vault 或 AWS Secrets Manager 动态拉取
- 日志中避免打印完整密钥，哪怕只是调试——
log.Printf("using jwt key: %s", key)是高危操作
最常被忽略的一点：密钥变更后，前端存储的 refresh token 若也依赖该密钥签名，必须同步失效策略，否则会形成安全盲区。
