Golang 实现文件内容的压缩归档与加密传输-Golang-PHP中文网

archive/zip压缩文件无需落盘，可直接用bytes.buffer或io.pipe构建内存归档；关键在于zip.newwriter绑定io.writer而非os.create，且必须调用zw.close()写入中央目录。

golang 实现文件内容的压缩归档与加密传输

如何用 `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）。

推荐用 PKCS#7 填充（不是 PKCS#5，二者在 Go 中等价，但语义更准确）：

填充字节数 = 16 - len(data)%16，若整除则补 16 字节
每个填充字节值等于填充长度（如补 3 字节，则填 0x03 0x03 0x03）
解密后必须校验填充有效性，不能只截掉末尾 N 字节——攻击者可能篡改填充破坏完整性

Go 标准库没内置 PKCS#7，需手写或用 golang.org/x/crypto/pkcs7（注意该包已归档，建议复制其填充逻辑而非依赖）。

Golang Naming

Go（Golang）命名规范 — 包括包、构造函数、结构体、接口、常量、枚举、错误、布尔值、接收器、getter/setter、函数等。

下载

加密传输时，为什么不能只加密 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