结论：AES-GCM分块加密+HTTP/HTTPS二进制流传输是最平衡安全、性能与实现成本的方案；CBC分块易出错且不适用于HTTP场景，因IV依赖破坏链式特性、填充复杂且无完整性校验。
直接说结论：用 AES-GCM 分块加密 + HTTP/HTTPS 二进制流传输，是最平衡安全、性能与实现成本的方案；别用 CBC 模式拼接分块，也别在 TCP 层自己搞加密协议——既难审计又易出错。
为什么不用 CBC 分块加密
CBC 模式要求前一块密文作为后一块的 IV，而分块传输天然割裂了数据连续性。如果把大文件切成 N 块分别用 CBC 加密（每块独立 IV），就失去了 CBC 的链式特性，退化为 ECB 风险；若强行让第 i 块的 IV = 第 i−1 块密文末 16 字节，则必须保证块严格对齐、顺序接收、不可丢包——这和 HTTP/TCP 的语义冲突，实操中极易解密失败或出现乱码。
更现实的问题是：cipher.NewCBCEncrypter 不支持“流式追加加密”，你得手动管理填充边界、IV 衍生逻辑，稍有不慎就会在块交界处解密失败，且无法校验完整性。
- 避免用
CBC做分块加密，除非你完全控制传输层（如 QUIC 自定义流）并能保证顺序+不丢包 - 若已有旧系统用
CBC，务必确保每块都做 PKCS#7 填充，并把 IV 固定写在每块开头（16 字节），不要复用 - 永远不要把上一块密文末尾当 IV —— 这在并发上传、重试、断点续传时必然崩溃
AES-GCM 分块加密的正确姿势
AES-GCM 是 Go 标准库原生支持的 AEAD 模式，单次调用 cipher.AEAD.Seal() 即完成加密+认证，输出密文+16 字节 tag；它不要求数据长度对齐，也不依赖前序密文，天然适合分块。
立即学习“go语言免费学习笔记（深入）”；
关键点在于：每个块必须用唯一 nonce（推荐 12 字节），且不能重复。最稳妥做法是把块序号嵌入 nonce：比如 nonce = append(make([]byte, 4), uint32(chunkIndex)...) // 前 4 字节留空，后 4 字节放序号，再补足到 12 字节（用 crypto/rand.Read 填充前缀）。这样即使同一文件重传，只要序号不变，nonce 就可复用（但注意：不同文件绝不可复用相同 nonce + 密钥组合）。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 每块加密前生成或构造唯一
nonce，随密文一起发送（建议前置在块数据开头） - 密钥绝不硬编码，生产环境通过环境变量注入或 KMS 获取；开发测试可用
scrypt.Key从密码派生 - 附加数据（
additionalData）建议传fileName + strconv.Itoa(chunkIndex)，增强防篡改能力 - 不要省略
Open()返回值检查：返回nil才算解密成功，否则直接丢弃该块
HTTP 上传时如何组织分块请求体
别用 multipart/form-data 包裹每块——边界开销大、解析慢、服务端难流式处理。直接 POST 原始二进制流，用自定义 header 描述元信息：
客户端请求示例：
POST /upload/chunk HTTP/1.1 Content-Type: application/octet-stream X-File-ID: abc123 X-Chunk-Index: 5 X-Total-Chunks: 12 X-Is-Last: false X-Nonce: <code>base64-encoded-12-byte-nonce</code>
服务端收到后，先读 header 提取 X-Nonce，再读 body 得到密文（含 GCM tag），用相同密钥初始化 AES-GCM 实例，调用 Open() 解密。解密成功即写入对应偏移的临时文件（如 os.WriteAt）。
- 避免在 URL 或 query string 里传
chunkIndex等参数——可能被代理截断或记录在日志中 -
X-Is-Last: true仅用于触发合并逻辑，不参与解密；最后一块仍需完整 GCM 校验 - 若需断点续传，服务端应提供
GET /upload/status?file_id=abc123接口返回已收块列表 - 不要用
io.Copy直接转发加密块——它不感知 GCM tag 长度，容易把 tag 当作数据写坏
最容易被忽略的三个细节
第一是 nonce 生命周期管理：同一个密钥下，nonce 一旦用过就不能再用。如果你用时间戳或随机数生成 nonce，却没持久化记录，重传时极可能复用，导致 GCM 完整性失效。
第二是解密后不校验原始文件哈希：哪怕每块 GCM 都通过，攻击者仍可能替换整块密文为另一合法密文（比如用已知明文构造）。应在上传开始前计算全文件 SHA256，作为 header（如 X-File-SHA256）发送，合并后比对。
第三是临时文件权限与清理：分块写入的临时文件若未设 0600 权限，可能被同主机其他用户读取明文；上传中断时，没被 IsLast 触发的临时文件必须有超时清理机制（如基于 mtime 的后台 goroutine 扫描）。
