金融级合规需传输层TLS、应用层AEAD加密、KMS密钥管理、审计日志四层闭环；禁用明文HTTP、硬编码密钥、弱密码套件及非认证加密模式。
金融级合规不是靠“加一层加密”堆出来的，而是由传输层、应用层、密钥管理、审计日志四层协同构成的闭环。单独在 http.Handler 里对 ResponseWriter 做 AES 加密，或把密钥写死在代码里，直接不满足 PCI DSS、等保三级或《金融数据安全分级指南》任一要求。
必须用 TLS，且证书要合法可验证
HTTP 明文通信在金融场景下属于高危违规行为，http.ListenAndServe 绝对禁止出现在生产代码中。TLS 不是“可选项”，而是准入门槛。
- 服务端必须使用
http.ListenAndServeTLS，且证书需来自受信 CA（如 Let’s Encrypt、CFCA）或企业私有 PKI；本地测试可用mkcert生成，但不能进生产镜像 - 客户端必须校验证书链：
http.Client默认行为已足够，禁用TLSClientConfig.InsecureSkipVerify = true—— 即使测试环境也应通过 mock CA 或自签名根证书方式绕过，而非跳过校验 - 禁用弱协议和密码套件：Go 1.19+ 默认已禁用 TLS 1.0/1.1，但仍需显式限制，例如在
tls.Config中设置MinVersion: tls.VersionTLS12和CipherSuites白名单（推荐仅保留TLS_AES_128_GCM_SHA256等 AEAD 套件）
AES-GCM 或 ChaCha20Poly1305 才是应用层加密的唯一可行选择
金融场景要求“密文不可篡改”，所以 CBC、ECB 这类无认证模式一律排除。AES-CBC + PKCS7 填充再加 HMAC 是常见错误组合——它不如原生 AEAD 安全、性能差、且易因时序差异引入侧信道风险。
- 优先用
golang.org/x/crypto/chacha20poly1305（ARM/移动端更优）或crypto/aes+cipher.NewGCM（x86 更优），两者都提供原子性加密+认证 -
Nonce必须每次唯一：ChaCha20Poly1305 要求 24 字节，AES-GCM 推荐 12 字节；严禁复用，也不能用时间戳或计数器硬编码——应从crypto/rand.Read安全生成 - 密文结构固定为
nonce || ciphertext || tag（GCM 的 tag 长度固定 16 字节），解密前必须完整切分，不能只截前 N 字节 - 不要在 HTTP header 中用
X-Encrypted控制加解密逻辑——这属于业务语义，应在 API 协议层定义（如 JSON payload 内嵌"encrypted": true），header 只传元信息（如算法标识）
密钥绝不能硬编码，必须走 KMS 或环境隔离注入
密钥明文出现在 Go 源码、配置文件、Dockerfile 或环境变量字符串里，等于把金库钥匙焊在门把手上。
立即学习“go语言免费学习笔记（深入）”；
- 生产密钥必须由 KMS（如 AWS KMS、阿里云 KMS、Vault）动态获取并解密，Go 代码只持有密文密钥（
encrypted key），启动时调用 KMS Decrypt API 获取明文后立即加载进内存，不落盘、不打日志 - 不同环境（dev/staging/prod）必须用不同 KMS 密钥加密同一逻辑密钥，避免密钥跨环境泄露后连带击穿
- 若暂无 KMS，至少用
os.Getenv+ init-time 注入，并确保容器运行时环境变量不被ps或/proc/$PID/environ泄露（如用 Docker secret 或 Kubernetes Secret mount） - 密钥长度必须匹配算法：AES-128 用 16 字节，AES-256 用 32 字节，ChaCha20Poly1305 固定 32 字节——错一位就会
cipher.NewChaCha20Poly1305: invalid key size
国密 SM4/SM2 仅在明确要求时启用，且必须用权威实现
金融客户若明确要求国密算法（如央行接口、政务云对接），不能自己“翻译”国密标准，也不能用非审计过的第三方库。
- SM4 加密必须用
github.com/tjfoc/gmsm/sm4（CFCA 审计过）或github.com/ZZMarquis/gm（国密局推荐），禁用任何自研或未审计的 SM4 实现 - SM2 密钥交换必须配合 SM4 使用：即用 SM2 公钥加密 SM4 密钥，再用该 SM4 密钥加密业务数据——不能直接用 SM2 加密原始 payload（SM2 仅支持 ≤ 117 字节明文）
- 所有国密操作必须记录算法标识（如
sm4-cbc、sm2-sign）和密钥 ID 到审计日志，且日志本身需加密存储、不可篡改 - 注意兼容性陷阱：SM4 的 ECB/CBC 模式无认证能力，生产环境必须搭配 SM3 哈希做完整性校验，或直接选用 SM4-GCM（部分新版本 gmsm 已支持）
最容易被忽略的点是密钥轮换和密文版本管理——金融系统上线后密钥不能一成不变，但旧密文仍需可解。这意味着加解密模块必须支持多密钥 ID 并存、按 version 字段路由解密，且密钥生命周期操作（生成、停用、归档）需与 KMS 审计日志对齐。没做这件事，合规审查时第一关就过不了。
