Golang标准库cipher.AES+NewGCM是最稳妥的文件加密方案：需用12字节唯一nonce、32字节随机密钥，文件结构为salt(16B)[ciphertext+tag]，解密时必须检查err!=nil而非返回值长度。
Go 里用 aes.GCM 加密文件最稳妥
直接上结论：Golang 标准库的 cipher.AES + cipher.NewGCM 是目前最常用、最安全的文件加密方案。它自带认证（AEAD），能同时防篡改和窃听，比手搓 CBC + HMAC 更可靠，也比第三方包少一层信任风险。
关键点在于：不能复用 nonce，密钥必须足够随机且长度合规（AES-256 要 32 字节），加密前先生成并写入 salt 和 nonce（通常拼在密文头部）。
-
nonce必须每次加密唯一，推荐用rand.Read()生成 12 字节（GCM 最佳长度） - 密钥不应硬编码，建议用
scrypt.Key()或pbkdf2.Key()从用户密码派生 - 加密后文件结构建议为：
[salt(16B)][nonce(12B)][ciphertext+tag]，解密时按偏移读取 - 别用
os.Create()直接覆盖原文件——万一出错就丢数据；应写临时文件 +os.Rename()
为什么不用 gob 或 json 包裹后再加密
有人想先序列化再加密，比如把 struct 用 gob.Encoder 编码成字节流，再喂给 AES。这看似方便，但实际埋了坑：
-
gob和json输出不固定：同一数据多次编码可能字节不同（尤其gob含类型信息、版本号），导致无法做确定性加密或校验 - 序列化本身不压缩，反而增大待加密体积；若原始文件已是二进制（如图片、PDF），再 gob 一层纯属冗余
- 如果只加密“内容”而忽略文件元信息（如修改时间、权限），解密后恢复困难；不如直接操作原始字节流 + 单独存 metadata
正确做法是：打开文件 → 按块读取（如 64KB）→ 每块单独加密 → 写入目标文件。这样内存可控，也兼容超大文件。
立即学习“go语言免费学习笔记（深入）”；
io.Copy 配合 cipher.Stream 的陷阱
有人查文档看到 cipher.Stream（如 newCFB）支持流式加解密，就直接套 io.Copy(dst, cipher.StreamWriter{...})。这在小文件上可能跑通，但隐患明显：
- CFB/OFB/CTR 等模式不带认证，攻击者可翻转密文某位，导致明文对应位翻转而不报错（即“malleability”）
-
io.Copy不保证整块对齐：若最后一次读不满缓冲区，Stream内部状态可能残留，导致后续解密错位 - 标准库的
Stream实现不校验输入长度是否为块大小整数倍，容易静默失败
除非你明确需要流式且能接受无认证（例如内网日志实时加密），否则一律优先选 aes.GCM。它虽要手动分块处理，但安全性边界清晰。
解密时如何判断文件是否被篡改或密钥错误
aes.GCM 的 Seal() 产出含 tag，Open() 会自动校验。但错误表现很隐蔽：如果密钥错、nonce 错或密文被改，Open() 只返回 nil, nil（不是 panic，也不是明确 error），容易误判为“解密成功但内容为空”。
- 务必检查
err != nil，而不是只看返回的[]byte是否为空 - 常见错误值是
cipher.ErrDecrypt，但该变量未导出；实际只需判断err != nil即可确认失败 - 不要依赖
len(dst)判断——即使 tag 校验失败，Open()也可能返回非空切片（内容不可信） - 若需区分“密钥错误”和“文件损坏”，可在加密时额外写入一个固定 magic header（如 4 字节
[]byte{0x47, 0x4f, 0x45, 0x4e}），解密后校验
最易被忽略的是：GCM 的 Open() 对输入长度敏感——如果传入的密文字节里没包含完整的 tag（默认 16 字节），它不会报错，而是直接返回 nil, nil。务必确保读取的字节数 ≥ 密文长度 + tag 长度。
