iris 不内置加解密功能，需开发者用标准库或第三方包手动实现；加密必须在业务层针对具体字段处理，禁用中间件自动加解密；推荐 aes-gcm 等 aead 模式，密钥须安全管理，数据库加密后影响查询能力。
Iris 是 Go 语言的 Web 框架，本身**不内置数据加密/解密功能**。它不提供类似 encrypt() 或 decrypt() 的封装函数，所有加解密逻辑需开发者自行引入标准库（如 crypto/aes、crypto/cipher）或第三方包（如 golang.org/x/crypto/chacha20poly1305）实现。
下面直说关键点：怎么做、为什么这么选、哪里容易出错。
加密字段必须在业务层手动处理，不能依赖 Iris 中间件自动加解密
Iris 的中间件（如 ctx.PostBody()、ctx.JSON()）只负责 HTTP 生命周期的数据流转，不干预数据内容语义。即使你写一个“加密中间件”，它也无法区分哪些字段该加、哪些是 salt、哪些是 IV —— 这些必须由业务逻辑明确指定。
- 常见错误：试图在
iris.Handler里统一 AES 加密整个req.Body，结果导致 JSON 解析失败或字段错位 - 正确做法：在 Controller 或 Service 层，对具体字段（如
user.Password、card.Number）调用封装好的加解密函数 - 注意：HTTP Header、Query 参数、Form 值都需单独处理，
Iris不会帮你做上下文感知的透明加解密
推荐用 AEAD 模式（如 AES-GCM），避免手写 CBC + PKCS7
Go 标准库的 crypto/aes 和 crypto/cipher 支持 CBC、GCM 等模式，但 AES-GCM 是更安全的选择 —— 它同时保证机密性与完整性，且无需额外处理 padding。
- CBC 模式易受填充预言攻击（Padding Oracle），尤其当错误信息暴露给客户端时（如返回
"invalid padding"） - GCM 要求传入唯一 Nonce（不是随机数，而是每把密钥下不可重用的值），建议用
crypto/rand.Read()生成 12 字节 Nonce 并和密文一起存储 - 示例关键片段：
block, _ := aes.NewCipher(key) aesgcm, _ := cipher.NewGCM(block) nonce := make([]byte, aesgcm.NonceSize()) rand.Read(nonce) ciphertext := aesgcm.Seal(nil, nonce, plaintext, nil) // 返回 nonce+ciphertext
密钥管理不能硬编码，也不能存在 config.json 里
Iris 应用启动时加载配置（如 iris.Configuration{...}），但密钥绝不能以明文形式出现在代码或配置文件中。否则部署到 CI/CD 或容器环境时极易泄露。
- 可行方案：从环境变量读取密钥派生材料（如
ENCRYPTION_SALT），再用crypto/sha256或golang.org/x/crypto/scrypt派生实际密钥 - 更稳妥做法：使用外部密钥管理服务（如 HashiCorp Vault、AWS KMS），通过 HTTP API 获取加密/解密能力，而非直接获取密钥
- 严重风险点：用相同密钥加密所有用户数据 → 一旦密钥泄露，全量数据可被批量解密；应考虑 per-user key 或 per-session key
数据库字段加密后会影响查询和索引
如果你对数据库某列（如 users.email_encrypted）做了服务端加密，那这个字段就失去了可搜索性 —— WHERE email_encrypted = ? 只能做等值匹配，无法支持 LIKE、范围查询、大小写模糊等操作。
- 替代思路：加密前先计算确定性哈希（如
sha256(email + user_id + pepper)）存为email_hash，用于精确查找；敏感原始值则另存加密字段 - 切勿用相同 IV 加密不同记录的同一字段，否则相同明文会产生相同密文，形成统计泄漏
- ORM（如 GORM）不会自动识别加密字段，
db.Where("email_encrypted = ?", enc).Find(&u)中的enc必须是已加密后的字节数组（[]byte），不是字符串
aes.NewCipher，而是决定“什么数据要加密”“加密到哪一层”“密钥怎么轮换”“错误时如何不泄密”。这些决策点不在框架里，而在你的领域模型和部署约束中。
