Base64不是加密而是编码，无法保密；微服务敏感配置必须用AES-GCM等真正加密算法，因其兼具机密性与完整性校验，可防篡改，且需严格遵循密钥长度（如AES-256须32字节）、随机Nonce生成及密文结构规范。
为什么不能直接用 base64 做配置加密
base64 不是加密，只是编码，base64 解码工具遍地都是，配置一旦泄露等于明文暴露。微服务里存数据库连接密码、API密钥这类敏感字段，必须用真正加密算法——比如 AES-GCM，它自带完整性校验，避免篡改后还能解出脏数据。
常见错误现象：crypto/aes: invalid key size 或解密后得到乱码，大概率是密钥长度不对（AES-256 要 32 字节）、IV 没复用或没传对。
- 密钥必须固定长度：AES-128 用 16 字节，AES-256 严格要 32 字节，别用字符串直接
[]byte("mykey")—— UTF-8 编码长度不等于字节数 - IV（初始化向量）每次加密都要随机生成，且必须和密文一起传输，不能硬编码或复用
- 不要自己拼接 salt + password 再
sha256当密钥——这属于 DIY 密钥派生，应使用golang.org/x/crypto/pbkdf2
如何用 crypto/aes 实现安全的加解密函数
Go 标准库 crypto/aes 配合 crypto/cipher 可以实现 AES-GCM，但要注意 GCM 模式下 cipher.NewGCM 返回的实例不是线程安全的，不能全局复用；每次加解密都应新建 cipher 实例或封装成带锁的池。
典型使用场景：配置中心下发前加密、服务启动时解密环境变量。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 加密函数签名建议为：
func Encrypt(key, plaintext []byte) ([]byte, error)，返回nonce + ciphertext拼接后的字节切片（nonce 通常 12 字节） - 解密函数必须先切出 nonce，再用相同 key 初始化 GCM，否则
cipher: message authentication failed - 密钥绝不硬编码，推荐从环境变量读取并做 hex decode：
hex.DecodeString(os.Getenv("AES_KEY_HEX"))
// 示例片段：加密
block, _ := aes.NewCipher(key)
aesgcm, _ := cipher.NewGCM(block)
nonce := make([]byte, aesgcm.NonceSize())
if _, err := rand.Read(nonce); err != nil {
return nil, err
}
return aesgcm.Seal(nonce, nonce, plaintext, nil), nil
配置中心集成时怎么避免密钥泄漏
把密钥塞进配置中心本身是反模式。正确做法是：密钥只存在于服务本地（如 /etc/secrets/aes-key 文件或 K8s Secret mount），配置中心只存加密后的值（如 ENC[AES-GCM,xxx...]），服务启动时读密钥、解密配置。
容易踩的坑：os.Getenv("AES_KEY") 从环境变量读密钥，但 Docker logs 或 ps aux 可能暴露进程参数；K8s 中若用 envFrom secret，仍可能被误配成 configMap。
- 密钥文件权限必须设为
0400，且由非 root 用户读取 - 禁止在日志中打印加密前/后的完整配置，尤其不能打
fmt.Printf("decrypted: %s", pwd) - 若用 Vault，走
kv/v2读密钥，配合token renewal，别用静态 token
服务间调用时怎么透传加密上下文
微服务链路中，下游服务可能也需要解密同一份配置（比如共享数据库密码），但不能让每个服务都存一份密钥。这时需统一密钥管理 + 上下文透传，而非重复加密。
关键点在于：加密操作只发生在配置写入侧（如配置中心后台），运行时所有服务只做解密；HTTP 请求头里透传的是加密后的值，不是密钥。
- 用自定义 header 如
X-Encrypted-Config传递加密 payload，格式保持简单：base64 编码后的nonce+ciphertext - 不要在 gRPC metadata 里传密钥或原始密文——metadata 默认会被日志记录，有泄漏风险
- 如果用 Istio，可在 sidecar 注入 Envoy filter 做透明解密，但要求密钥统一注入到所有 pod 的 volume 中
最麻烦的地方其实是密钥轮换：旧密钥加密的数据还没全下线，新密钥已启用，解密逻辑得支持多密钥 fallback，而 crypto/aes 本身不提供密钥版本管理，得自己在解密函数里加 try-catch 多次尝试。
