archive/zip压缩文件无需落盘，可直接用bytes.Buffer或io.Pipe构建内存归档；关键在于zip.NewWriter绑定io.Writer而非os.Create，且必须调用zw.Close()写入中央目录。
如何用 archive/zip 压缩文件但不写入磁盘
压缩归档必须落盘再读取？不是。直接构建内存中的 *zip.Writer，配合 bytes.Buffer 或 io.Pipe 就能避免临时文件。关键在于别调用 os.Create，而是把 zip.NewWriter 绑定到一个可写接口上。
常见错误是误以为 zip.Writer 需要真实文件路径——它只认 io.Writer。比如：
buf := new(bytes.Buffer)
zw := zip.NewWriter(buf)
f, _ := zw.Create("data.txt")
f.Write([]byte("hello")) // 写入内容
zw.Close() // 必须调用，否则结尾数据丢失注意：zw.Close() 不仅关闭流，还写入 ZIP 中央目录结构，漏掉会导致解压失败。
crypto/aes 加密前必须处理的块对齐问题
AES 是分组密码，要求明文长度是 16 字节倍数。直接对任意长度的压缩数据加密会 panic 或静默出错（如 crypto/cipher: message too short）。
立即学习“go语言免费学习笔记（深入）”；
推荐用 PKCS#7 填充（不是 PKCS#5，二者在 Go 中等价，但语义更准确）：
- 填充字节数 =
16 - len(data)%16，若整除则补 16 字节 - 每个填充字节值等于填充长度（如补 3 字节，则填
0x03 0x03 0x03） - 解密后必须校验填充有效性，不能只截掉末尾 N 字节——攻击者可能篡改填充破坏完整性
Go 标准库没内置 PKCS#7，需手写或用 golang.org/x/crypto/pkcs7（注意该包已归档，建议复制其填充逻辑而非依赖）。
加密传输时，为什么不能只加密 ZIP 数据而不加认证？
单纯 AES-CBC 或 AES-CTR 加密后传输，攻击者仍可翻转密文比特，导致解密后数据被可控篡改（如修改文件名、注入恶意内容）。这不是理论风险——ZIP 解析器对损坏结构容忍度高，容易绕过校验。
必须启用认证加密（AEAD），推荐 crypto/aes + crypto/cipher.NewGCM：
- GCM 模式同时提供机密性与完整性，解密时自动校验
nonce和密文标签 -
nonce必须唯一且不可预测，建议用crypto/rand.Read生成 12 字节 - 传输时需将
nonce+ 密文 + 标签（GCM 的Overhead默认 16 字节）一并发送，顺序固定
示例片段：
aesBlock, _ := aes.NewCipher(key) aesGCM, _ := cipher.NewGCM(aesBlock) nonce := make([]byte, aesGCM.NonceSize()) rand.Read(nonce) ciphertext := aesGCM.Seal(nil, nonce, zipData, nil)
接收端解密解压失败的三个高频原因
调试时最常卡在这三处，而不是算法本身：
-
zip.NewReader接收的是io.Reader，但传入的是未重置偏移的bytes.Buffer—— 必须用bytes.NewReader(ciphertext)或调用buf.Bytes()后重新构造 reader - 解密用的
key或nonce与发送端不一致，尤其注意 base64 编码/解码是否多空格、换行符 - ZIP 文件内含相对路径（如
./config.json），解压时默认保留路径，若目标目录权限不足或存在路径穿越（../），zip.File.Open可能静默失败或报permission denied
真正麻烦的不是加密或压缩本身，而是边界条件：填充是否干净、nonce 是否复用、ZIP 目录结构是否含非法字符、buffer 是否被多次读取。这些地方一错，整个流程就断在你看不见的地方。
