不能用 os.readfile/os.writefile 做透明加解密流，必须封装 io.reader/io.writer 并严格管理块对齐、iv/nonce 生命周期；cbc/gcm 需分块处理、pkcs#7 填充、避免 blockmode 复用；iv/nonce 必须随密文传输；gzip/image 等需解密后使用。
直接上结论：不能用 os.ReadFile/os.WriteFile 做透明加解密流，也不能把 crypto/cipher.BlockMode 直接连到 io.Copy —— 会丢块、错填充、解密失败。必须自己封装 io.Reader 和 io.Writer，并严格管理块对齐与 IV/nonce 生命周期。
io.Reader 封装加密流时为什么必须分块处理
- 加密不是“整个字节流过一遍”，而是按固定块（AES 是 16 字节）处理，且 CBC/GCM 模式依赖前一块输出或 nonce
-
io.Read不保证每次读到的长度是块大小倍数；比如你期望读 64KB，系统可能只给 37 字节，导致最后一块无法正确填充或加密 - 常见错误现象：
cipher.NewCBCEncrypter(...).CryptBlockspanic “len(src) not multiple of block size” 或解密后image.Decode报 “invalid PNG header”
实操建议：
- 用固定缓冲区（如 64KB）配合
io.ReadFull+ 手动填充逻辑，而不是直接传给CryptBlocks - 对最后一块单独判断：若不足 16 字节，执行 PKCS#7 填充（GCM 模式不用填，但需确保明文完整）
- 不要复用同一个
cipher.BlockMode实例跨多次Read调用——CBC 模式状态会污染，GCM 的 nonce 必须唯一
io.Writer 封装解密流时 IV/nonce 怎么安全传递
- 解密端必须在读取密文前先拿到 IV（CBC）或 nonce（GCM），而它们必须随数据一起传输，不能硬编码或从别处查
- 错误做法：把 IV 存配置文件、或写死在代码里；更糟的是“解密时生成新 IV 再去试”，这根本不可行
- 正确结构：密文文件 =
IV(16B)+密文（CBC） 或nonce(12B)+密文+tag（GCM）
实操建议：
- 封装
io.Reader解密器时，首次Read前先调用io.ReadFull(r, iv)提取头部 - 若用 GCM，
aesgcm.Open需要完整密文+tag，所以得缓存至少一个完整 GCM 输出块（通常 16B tag 在末尾，但你读的是流式前置——得把 nonce 读出后，再把后续所有字节攒够再解） - 切勿在
Read方法里做os.Open或rand.Read—— 这违反流语义，且并发不安全
为什么 gzip.NewReader 不能和加密流混用，以及怎么绕过
-
gzip.NewReader会立即尝试从底层io.Reader读取魔数和头信息（至少 10 字节），如果此时加密流还没吐出足够字节（比如刚初始化、IV 还没读完），就直接返回EOF或invalid header - 同理，
image.Decode也依赖前若干字节识别格式（PNG 是 8 字节，JPEG 是 2 字节 SOI），加密后这些字节被搅乱，必须等解密完成才能交过去
实操建议：
- 不要在同一层叠加密 + gzip；要么先压缩再加密（适合存储），要么先加密再解密后解压（适合传输）
- 如果真要链式处理（如加密 → gzip → 网络发送），用
io.Pipe拆开：一端 go 协程做加密写入 pipe，另一端从 pipe 读并 gzip 压缩 -
image.Decode类函数永远只接收已解密完的原始字节流，不要试图喂它加密后的bytes.Buffer
真正难的不是写加密逻辑，而是让加密行为“透明”：用户调 io.Copy(dst, src)，src 是个 <em>decryptReader</em>，dst 是个 encryptWriter，中间不报错、不卡死、不解出乱码。这要求每一块读写都对齐、每一段元数据都可定位、每一个 error 都能立刻终止且不残留敏感内存——而这些，标准库一个都没帮你做。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
