增量加密的本质是“追加写入+密钥隔离”，需每段明文独立加密：生成唯一IV，用AES-GCM（推荐）或AES-CBC+HMAC，将IV、密文、认证标签按固定格式持久化，并通过HKDF基于主密钥和段序号派生子密钥，确保各段密钥隔离、IV绑定、可独立解密。
增量加密的本质是“追加写入+密钥隔离”，不是简单套AES
直接用 AES 对每次新内容单独加密再拼接，会导致解密失败或数据错位——因为 AES 的 CBC 模式依赖前一块密文，ECB 模式又不安全。真正的增量加密必须让每段加密结果自包含、可独立解密，且密钥/IV 不复用。
常见错误现象：crypto/cipher: invalid buffer size for block cipher 或解密后出现乱码、截断，往往是因为把多段密文当成连续流去解密，或者 IV 没随数据一起保存。
- 每段明文应独立加密：生成唯一
iv，用AES-GCM（推荐）或AES-CBC+HMAC组合 -
iv和认证标签（如 GCM 的authTag）必须与密文一起持久化，通常按iv|ciphertext|authTag格式追加 - 密钥不能硬编码，建议用主密钥派生出段级密钥（如通过
HKDF+ 段序号），避免单点泄露影响全部历史数据
用 crypto/aes + crypto/cipher/gcm 实现可追加的加密写入
Golang 标准库的 gcm 是最稳妥的选择：它自带认证、自动处理 IV、无需手动管理 padding，且输出长度固定可预测（ciphertext = plaintext + 12（IV len） + 16（auth tag））。
关键点在于：每次写入都要新建 cipher.AEAD 实例，用随机 iv 加密，并把 iv 前缀到密文里——不是“初始化一次然后反复 Write”，那是流式加密，不适合增量场景。
立即学习“go语言免费学习笔记（深入）”；
func appendEncrypted(f *os.File, key []byte, plaintext []byte) error {
block, _ := aes.NewCipher(key)
aead, _ := cipher.NewGCM(block)
iv := make([]byte, aead.NonceSize())
if _, err := rand.Read(iv); err != nil {
return err
}
ciphertext := aead.Seal(nil, iv, plaintext, nil)
// 写入：iv + ciphertext（含 auth tag）
if _, err := f.Write(append(iv, ciphertext...)); err != nil {
return err
}
return nil
}
注意：aead.Seal 输出已包含认证标签，长度 = 明文长度 + aead.Overhead()（通常是 16 字节），不要额外再算 tag 长度。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
读取时必须按块解析，不能全文一次性解密
文件是多个加密块拼接而成，没有分隔符或长度头，所以必须知道每个块的结构才能拆分。最可靠的方式是：预先约定 IV 长度（GCM 固定为 aead.NonceSize()，通常 12）、tag 长度（aead.Overhead()，通常 16），然后循环读取。
典型错误：用 io.ReadAll 读完整文件再尝试解密，结果因 IV 错位导致所有块失败。
- 每次读取至少
ivLen + minPlaintextLen + overhead字节（比如 12 + 1 + 16 = 29），否则无法解密任意一块 - 解密前要校验密文长度是否 ≥
ivLen + overhead，否则数据损坏或被截断 - 如果某块解密失败（
crypto/aes: invalid authentication tag），应跳过或报错，不要影响后续块
密钥管理比算法更易出问题：别用全局变量存 key
很多实现把密钥存在包级变量或配置文件里，一旦泄漏，所有历史数据瞬间裸奔。增量存储天然有时间维度，应该利用这点做密钥分层。
推荐做法：主密钥（如从 KMS 获取）只用于派生，每段加密使用 HKDF + 段索引（如写入时间戳或递增 ID）生成子密钥：
func deriveKey(masterKey, salt []byte, segmentID uint64) ([]byte, error) {
hkdf := hkdf.New(sha256.New, masterKey, salt, []byte(fmt.Sprintf("segment-%d", segmentID)))
key := make([]byte, 32)
if _, err := io.ReadFull(hkdf, key); err != nil {
return nil, err
}
return key, nil
}
这样即使某一段密钥泄露，也无法推导其他段；删除某段数据时，连同其派生密钥一并丢弃，真正实现“按需解密”。
真正麻烦的是 IV 存储位置和密钥生命周期对齐——IV 必须和对应密文在同一个原子写入中落盘，而密钥派生必须在写入前完成，这两步若被中断，就会出现“有密文无 IV”或“有 IV 无密钥”的脏数据。
