AES-GCM是Go中文件加密最稳妥的选择，因其兼具机密性与完整性且通过FIPS验证；需用12字节唯一nonce、安全随机密钥、流式加解密，并配合salt与PBKDF2派生密钥。
用 aes.GCM 做文件加密最稳妥
Go 标准库的 crypto/aes + crypto/cipher 组合支持 AEAD 模式，aes.GCM 是目前推荐的默认选择：它同时保证机密性与完整性，且 Go 实现已通过 FIPS 验证路径（如启用 crypto/tls 时的行为可作参考）。别用 CBC 或 ECB —— 它们不带认证，解密后无法判断数据是否被篡改，实际等于裸奔。
关键点：
-
GCM要求固定长度的 nonce（12 字节最常用），每次加密必须唯一，但不必保密 - 密钥必须是 16 字节（AES-128）、24 字节（AES-192）或 32 字节（AES-256），不能直接用字符串硬编码
- 加密后需把
nonce和密文一起保存，否则无法解密；通常前置 12 字节存 nonce
os.OpenFile + io.Copy 流式加解密才不爆内存
读整个文件进 []byte 再加密，遇到几百 MB 的日志或备份文件就直接 OOM。正确做法是用管道流式处理：开两个 goroutine，一个读明文块、加密、写入目标文件；另一个负责协调错误传递。标准库的 io.Copy 天然适配 cipher.AEAD 封装的 writeCloser。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
os.Open打开源文件，os.Create创建目标文件（注意权限：0600） - 调用
block, _ := aes.NewCipher(key)，再aead, _ := cipher.NewGCM(block) - 生成随机
nonce := make([]byte, aead.NonceSize())，rand.Read(nonce) - 用
aead.Seal()包装写入器，或更简单：用io.Copy向aead.Seal(nil, nonce, plaintext, nil)的结果写入
密钥管理不能跳过 crypto/rand，别手动生成
用 "password" 当密钥、或用 md5("mypassword") 衍生，等同于把锁换成贴纸。真实场景必须用密码学安全的随机源生成密钥，或使用 scrypt.Key / pbkdf2.Key 从口令派生 —— 且必须带 salt 和足够迭代轮数。
Word报告自动生成神器。自动生成专业Word文档报告，支持模板填充、目录生成、表格/图表插入、页眉页脚、多级标题、样式主题、批量邮件合并。当用户需要生成Word报告、创建合同文档、批量生成通知/证书、填充Word模板、制作商业计划书时触发。
常见错误：
- 用
math/rand生成密钥 → 输出可预测，完全不安全 - 复用同一 salt 对多个文件派生密钥 → 丧失唯一性保障
- 省略 salt 存储 → 解密时无法还原原始密钥
示例（派生密钥）：
salt := make([]byte, 16)
_, _ = rand.Read(salt) // 必须用 crypto/rand
key := pbkdf2.Key([]byte("user-pass"), salt, 100000, 32, sha256.New)
解密失败时 crypto/cipher 只返回 invalid ciphertext，没更多信息
这是设计使然：为防止旁路攻击，GCM 验证失败一律返回同一个错误，不区分是 nonce 错、密钥错，还是密文损坏。所以你得自己加一层上下文包装，比如在加密时写入文件头（magic bytes + version），解密前先校验；出错时结合文件大小、header 是否存在来缩小排查范围。
典型陷阱：
- 把加密后的文件当文本打开并“手动修改”几个字节 → GCM 验证必败，但错误信息看不出是人为破坏
- 跨平台传输时用了 FTP 的 ASCII 模式 → 换行符被转义，密文结构被破坏
- 读取文件时没设
os.O_RDONLY，误开了写权限导致文件被截断
真正难调试的，永远不是算法调用本身，而是密钥、nonce、salt、文件边界这四样东西里有一个没对齐。
