AES-GCM 是首选，因其同时提供机密性与完整性校验，而 AES-CBC 需额外加 HMAC 且易出错；Go 的 cipher.AEAD 接口强制 nonce 和附加数据，规避重复 nonce 风险。
为什么 AES-GCM 是首选，而不是 AES-CBC 或 crypto/aes 原始块加密
因为 AES-GCM 同时提供机密性与完整性校验，而 AES-CBC 本身不防篡改，必须额外加 HMAC；手写 CBC+HMAC 组合极易出错（比如先解密再验证），AES-GCM 把这事封装进一个 cipher.AEAD 接口里，一步到位。
Go 标准库的 crypto/cipher 包中，gcm.NewGCM 返回的就是符合 cipher.AEAD 接口的实例，它强制你传入 nonce 和附加数据（哪怕为空），天然规避“重复 nonce 导致密钥泄露”这类低级但致命的问题。
-
nonce必须唯一，但不必保密；常见做法是用 12 字节随机值（crypto/rand.Read），不要复用 - 密钥长度必须是 16（AES-128）、24（AES-192）或 32（AES-256）字节；用
sha256.Sum256派生密钥时注意截取长度 - 加密后输出 =
nonce+ciphertext+auth tag（16 字节），解密时要按顺序拆分
os.OpenFile 和 io.Copy 怎么配合 AES-GCM 加密大文件而不爆内存
不能把整个文件读进 []byte 再加密——几 GB 的文件直接 OOM。得用流式处理：开两个 io.Reader / io.Writer 管道，一边读原始文件，一边写加密后的内容。
关键点在于：AES-GCM 的 Seal 方法不支持流式加密，但你可以分块加密每一块（比如 64KB），每块用独立 nonce（需记录偏移或递增），或者更简单：只在开头生成一个 nonce，把整个文件当“单个明文”塞给 Seal ——前提是内存能扛住。对真正的大文件，推荐用 gobuffalo/packr/v2 或 google/wire 这类工具链预处理，而非硬刚流式 AEAD。
立即学习“go语言免费学习笔记（深入）”；
- 小文件（os.ReadFile →
aead.Seal→os.WriteFile - 中等文件（10MB–500MB）：用
bufio.NewReader分块读，每块加密后Write到目标文件，nonce放文件头 - 大文件（>500MB）：考虑改用
chacha20poly1305（标准库也支持），它对长流更友好；或引入外部工具如age命令行工具调用
解密失败时常见错误：不是密钥错，而是 nonce 长度不对或被截断
Go 的 aead.Open 如果返回 cipher.ErrInvalidLength 或静默失败（返回空数据），八成是 nonce 长度没对上。GCM 默认期望 12 字节 nonce，如果你存了 16 字节或只传了前 8 字节，就会失败。
另一个坑是：加密时用了 make([]byte, 12) 生成 nonce，但写文件时误用 binary.Write 写成了带长度前缀的格式，导致解密读出来的 nonce 多了 4 字节。
- 加密后文件结构建议固定为：
[12-byte nonce][ciphertext][16-byte tag] - 解密时用
io.ReadFull读前 12 字节到nonce切片，别用Read+len判断 - 测试时故意改一个字节的
nonce，确认是否报cipher.ErrAuth而非 panic ——这是验证 AEAD 是否生效的关键信号
如何安全地从用户输入派生 AES 密钥：别直接用 md5(password)
md5、sha1、甚至裸 sha256 都不适合直接当密钥——它们太快，容易被暴力破解。必须用密钥派生函数（KDF），Go 标准库提供 golang.org/x/crypto/scrypt 和 pbkdf2。
scrypt 更抗 GPU 暴力，但需要更多内存；pbkdf2 更通用，适合兼容旧系统。无论选哪个，参数不能硬编码默认值：迭代次数至少 1（262144），salt 必须随机且存进加密文件头（比如紧跟在 <code>nonce 后面）。
- 示例 salt 生成：
salt := make([]byte, 16); rand.Read(salt) - 派生密钥后务必检查长度：
if len(key) != 32 { panic("bad key length") } - 永远不要把 password 明文留在内存里；用
golang.org/x/crypto/ssh/terminal读密码，读完立刻bytes.Fill清零
