加密文件结构必须固定偏移：salt（32字节）、nonce（12或16字节）、密文、auth tag（16字节末尾）；字段级加密需手动遍历viper配置map匹配ENC前缀；索引字段宜用确定性加密或明文哈希辅助。
加密文件结构必须固定偏移才能准确定位
直接读整个密文再解密会爆内存，但又不能靠“找某个 magic 字节”来定位 IV 或 tag——GCM 模式下这些字段长度固定且必须严格按序排列。真实项目里，索引定位出错的根源几乎都来自结构不统一。
- IV（或 nonce）必须前置，且长度锁定为
12字节（AES-GCM 推荐值）或16字节（CBC 模式），不能动态推断 - auth tag 固定
16字节，必须放在密文末尾，不能插在中间或省略 - 文件头部若含 salt（如用 scrypt 派生密钥），必须明确约定长度（常见
32字节），并在解密时硬编码读取偏移 - 别依赖文件扩展名或注释行做定位——加密后全是二进制，任何文本解析逻辑都会失效
大文件流式解密时如何避免块边界错位
分块读取不是为了“快”，而是为了内存可控；但 GCM 不支持真正意义上的流式加解密（tag 必须最后生成/验证），所以“块”在这里指的是缓冲区单位，不是加密单位。错位的后果是：最后一块解密失败、cipher.ErrAuthentication 报错、甚至静默返回乱码。
- 缓冲区大小设为
65536（64KB），且必须是16的倍数（AES 块大小），避免跨块截断填充字节 - 加密端写入顺序必须是：
salt（可选）→nonce→密文块1→ … →密文块N→auth tag - 解密端读取时，先跳过固定头部（如
32 + 12 = 44字节），再按缓冲区大小读密文主体，最后单独读末尾16字节作为 tag - 绝不能用
io.Copy直接对接cipher.Stream——AES-GCM 没有 Stream 接口，强行套用会导致认证失败
viper 读配置后怎么安全地定位 encrypted 字段
配置文件加密不是“全文件加密”，而是字段级加密，所以定位目标不是字节偏移，而是键路径。viper 自身不提供字段解密钩子，必须手动遍历 map 结构。
- 调用
viper.AllSettings()获取顶层map[string]interface{}，而非viper.GetString("database.password")—— 后者拿不到原始密文字符串 - 递归遍历时检查每个叶子节点是否为
string类型，并匹配预设敏感路径列表（如["database.password", "redis.auth"]） - 匹配到后，用
strings.HasPrefix(val, "ENC[AES-GCM]::")判断是否为密文，再切掉前缀提取 base64 内容 - 解密后直接覆写该 map 中对应键的值，不要调用
viper.Set()—— 它不支持嵌套路径赋值
数据库字段加密后如何避免查询索引失效
加密字段无法走传统 B-tree 索引，但业务又常需按手机号、邮箱等查用户。硬加密+全表扫不是解法，得在加密方式和查询模式之间做权衡。
立即学习“go语言免费学习笔记（深入）”；
- 对需要索引的字段（如手机号），改用 deterministically encrypted（确定性加密），即相同明文始终生成相同密文 —— 但仅限低熵字段，且密钥绝不能复用
- 使用
aes.NewCipher+cipher.NewCBCEncrypter配合固定 IV（仅限此场景），确保加密结果可预测；但必须隔离密钥，不同租户/环境用不同密钥防碰撞 - 更稳妥的做法是：保留一个明文辅助索引字段（如
phone_hash），存sha256(phone)，加密主字段同时写入哈希值，查询时用哈希匹配 - 千万别在 WHERE 子句里对加密字段做
LIKE或函数运算——MySQL/PostgreSQL 都无法下推索引，必然全表扫
