最稳妥的加密组合是直接用 cipher.NewGCM 加密后再走 HTTPS；必须用 12 字节 nonce（gcm.NonceSize() 固定值），复用 nonce 会导致安全模型失效，salt 与 nonce 需分开随机生成并前置存储，密文结构应为 salt(16B)+nonce(12B)+ciphertext+tag，大文件需分块加密且缓冲区大小避开 16 倍数陷阱，写入须用临时文件原子替换。
直接用 cipher.NewGCM 加密后再走 HTTPS 是当前最稳妥的组合；别碰 CBC + 手动 HMAC，也别在 HTTP 层自己加解密。
为什么必须用 12 字节 nonce 而不是 16 字节 IV
NewGCM 要求 nonce 长度严格等于 gcm.NonceSize() 返回值（固定为 12），传 16 字节会 panic："invalid nonce size"。这不是兼容性问题，是硬性校验。
- nonce 复用一次，GCM 安全模型即失效——攻击者可恢复密钥
- 每次加密前必须调用
crypto/rand.Read(nonce[:])，且检查 error - 不能用时间戳、PID 或计数器生成 nonce——这些都可能重复
- 写入文件时，nonce 必须前置，且长度硬编码为 12 字节；读取时按偏移切：
buf[0:12] - salt 和 nonce 必须分开：salt 用于密钥派生（如 PBKDF2），nonce 仅用于本次加密，两者都要随机、都要存
大文件不能用 io.Copy 直接套 cipher.Stream
看到 cipher.Stream（如 CFB）支持流式接口，就写 io.Copy(dst, cipher.StreamWriter{})，结果小文件看似正常，大文件末尾乱码或解密失败——因为 io.Copy 不保证块对齐，而 AES 分组密码内部仍按块处理，最后一块若未填满会导致填充错乱。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确做法：用固定缓冲区（如
64 * 1024）分块读取，每块单独调用gcm.Seal()加密后写入 - 缓冲区大小避开 16 的倍数陷阱（如
65535），推荐65536或131072 - 最后一块不足缓冲区大小？
gcm.Seal()仍可安全处理，无需手动补零或 PKCS#7 填充 - 别用
bufio.Reader包裹文件句柄再流式加密——它会干扰底层Read的字节边界
密文结构必须固化：salt + nonce + ciphertext+tag
密文不能光存数据，解密端根本不知道怎么拆。常见错误是只写 nonce、漏 salt，或把 salt 和 nonce 长度写死但没对齐——比如 salt 写了 16 字节，读的时候却从 buf[0:8] 开始取。
立即学习“go语言免费学习笔记（深入）”；
- 推荐结构：
[salt(16B)][nonce(12B)][ciphertext+tag]，总长 =16 + 12 + len(明文) + 16 - 生成
salt用crypto/rand.Read(salt)，不能复用，不能用时间戳 - 写入顺序必须严格：先
salt，再nonce，最后密文；读取时按偏移硬切，不依赖 magic 字节或分隔符 - 别用
os.Create()直接覆盖原文件——应写临时文件（如dst + ".tmp"），成功后再os.Rename()
真正难的不是写对一行 gcm.Seal()，而是让 salt、nonce、tag 的偏移和生命周期在所有环节里严丝合缝——少一个字节错位，整个密文就不可逆。
