必须先计算sha256校验值并写入归档头或单独文件，再加密；aes-gcm为最优选择，要求nonce随机唯一（12字节）、密文格式为nonce||ciphertext||tag，并严格验证auth tag后才解包。
加密前必须先确认文件完整性校验方式
直接对原始文件加密再归档，出问题后无法判断是传输损坏、解密失败还是归档解包错误。建议在加密前先计算 sha256.Sum256，把哈希值作为元数据写入归档头（或单独存为 .sha256 文件），而不是依赖归档工具自带的校验（如 tar --format=pax 不保证加密后仍可读）。
常见踩坑点：
- 用
os.Stat()获取的ModTime做唯一标识 —— 多次归档同内容文件会冲突 - 把哈希嵌进文件名（如
data.enc-abc123）—— 解密脚本需额外解析，易出错 - 跳过校验直接解密解包 —— 一旦密钥错或文件截断，报错位置模糊（可能显示
gzip: invalid header而非“密文损坏”）
选对 AES 模式：GCM 是目前最稳妥的选择
AES-GCM 同时提供机密性与完整性验证，比 CBC+HMAC 组合更简洁、不易手误。标准库 cipher.AEAD 接口强制要求传入 nonce，避免重用导致密钥泄露。
实操要点：
- nonce 必须随机且唯一：用
crypto/rand.Read(nonce[:])，长度严格为12字节（GCM 最佳实践） - 密文输出格式建议为
nonce[12] || ciphertext || auth_tag[16]，不额外加字段分隔符 —— 解析时按固定偏移切片更快 - 别用
ECB或裸CBC：前者完全不安全，后者需自己实现 PKCS#7 填充和 HMAC 校验，容易漏掉padding oracle防护
归档层用 archive/tar + gzip，但别让加密逻辑耦合进 Writer 链
常见错误是把 gzip.Writer → encryptWriter → os.File 串成一条流，导致某环节 panic 时资源泄漏或部分写入。正确做法是分两步：先构建内存中完整 tar 数据（bytes.Buffer），再整体加密写盘。
原因很实际：
-
tar.Header.Size在加密后会变（因填充和 tag），如果边 tar 边加密，header 里写的 size 就不准，解包失败 -
gzip.BestSpeed等压缩等级影响密文长度，进而影响 AEAD 认证结果 —— 必须固定压缩参数，建议用gzip.NoCompression避免非确定性 - 大文件场景下，全载入内存不现实？那就改用临时文件：
os.CreateTemp("", "archive-*.tar")，加密完成再os.Rename
解密归档时，优先验证 auth tag 再尝试解包
AEAD 的 Open 方法失败时，返回的 error 是 cipher.AEADDecryptError，不是通用 error。必须显式判断类型，否则会把密钥错误当成“文件不存在”之类误导性错误。
关键代码片段示意：
plaintext, err := block.Open(nil, nonce[:], ciphertext, nil)
if errors.Is(err, cipher.ErrInvalidLength) {
return fmt.Errorf("invalid ciphertext length")
}
var decryptErr cipher.AEADDecryptError
if errors.As(err, &decryptErr) {
return fmt.Errorf("decryption failed: auth tag mismatch (wrong key or tampered data)")
}
// 此时才开始 bytes.NewReader(plaintext).(*tar.Reader)
另外，tar.Reader 的 Next() 可能返回 io.ErrUnexpectedEOF，这往往是因为解密后数据被截断 —— 不能直接重试，得先检查原始加密文件大小是否匹配预期（nonce+密文+tag 总长是否合理）。
真正麻烦的是密钥管理：硬编码密钥、用时间戳当 salt、把密码明文存配置文件……这些都会让整个加密形同虚设。生产环境务必用 golang.org/x/crypto/argon2 衍生密钥，并把 salt 单独存归档头前 16 字节。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
