Go zip.File.OpenRaw 与 Open 有什么区别

直接结论：zip.File.Open 读取的是成员解压后的逻辑内容，适合文本解析、JSON 解码、内容哈希和普通解压；zip.File.OpenRaw 读取的是 ZIP 内保存的原始压缩载荷，适合不解压地搬运压缩数据或实现底层归档工具。两者不是“一个快、一个慢”的替代关系，而是数据语义不同。

官方文档：https://pkg.go.dev/archive/zip

最容易踩坑的场景，是代码在测试 ZIP 上似乎正常，换一批文件后 JSON、图片或文本解析突然失败。问题往往不在解析器，而在于调用方把 OpenRaw 返回的压缩字节当成了文件正文。

影响面：读取成功不代表拿到了文件正文

假设一个归档检查服务遍历 Reader.File，读取每个成员后计算哈希、识别类型并解析内容。为了“少一次解压”，实现者把 f.Open() 换成 f.OpenRaw()。调用本身没有报错，io.ReadAll 也能得到字节，但后续会出现三类异常：

• JSON 解码报首字符非法，文本不再可读；
• 同一份业务文件重新压缩后，哈希发生变化；
• 调用方以为校验了内容，实际只处理了压缩载荷。

这不是随机故障。只要成员的 Method 是 zip.Deflate 或其他压缩方法，OpenRaw 交付的就不是业务层看到的文件内容。

时间线：为什么 Store 成员会让问题潜伏

这类混用之所以难发现，是因为 zip.Store 的成员没有压缩。对它来说，原始载荷与逻辑内容的字节可能相同，于是错误实现能在少量样例上通过。后来归档写入器改用默认的 Deflate，或者上游传来真正压缩的成员，差异才暴露。

因此，不能用“我读出来的字节看着正常”判断 API 是否选对。先定义需要的是文件内容还是归档载荷，再选择方法。

触发条件：Deflate 让两种数据形态彻底分开

zip.File 同时保存成员元数据和定位信息。Open 会根据 FileHeader.Method 选择解压器，返回 io.ReadCloser；调用方读取到的是解压后的内容，并应关闭返回值。官方文档还说明，普通调用者应优先使用这条路径，因为它会透明解压并校验校验和。

OpenRaw 则返回普通 io.Reader，不解压成员。它没有成员级 Close，但读取仍依赖底层 ZIP 数据源；如果归档由 zip.OpenReader 打开，底层 ReadCloser 必须在原始读取结束后再关闭。

根因：混淆了逻辑内容与归档载荷

可以从四个维度快速区分两个方法：

还有一个容易漏掉的细节：通过 Open 读取时，应把内容读到 EOF 并处理读取错误。CRC 或长度问题可能在读取过程中才暴露；只成功调用 Open，不能证明整个成员内容已经通过校验。

修复动作：业务读取统一使用 Open

如果目标是计算“解压后文件内容”的 SHA-256，应使用 Open，让 io.Copy 读到 EOF，并同时处理读取和关闭错误：

package main

import (
    "archive/zip"
    "crypto/sha256"
    "encoding/hex"
    "fmt"
    "io"
)

func contentSHA256(f *zip.File) (string, error) {
    // Open 返回解压后的逻辑内容，并负责对应压缩方法的解码。
    rc, err := f.Open()
    if err != nil {
        return "", fmt.Errorf("打开成员 %q: %w", f.Name, err)
    }

    h := sha256.New()
    // 读到 EOF，确保把读取阶段出现的长度或校验错误返回给调用方。
    _, copyErr := io.Copy(h, rc)
    closeErr := rc.Close()
    if copyErr != nil {
        return "", fmt.Errorf("读取成员 %q: %w", f.Name, copyErr)
    }
    if closeErr != nil {
        return "", fmt.Errorf("关闭成员 %q: %w", f.Name, closeErr)
    }

    return hex.EncodeToString(h.Sum(nil)), nil
}

同理，把成员交给 json.Decoder、图片解码器或文本处理器时，也应该传入 Open 的结果。若担心压缩炸弹或超大成员，结合 UncompressedSize64 做预检查，并用 io.LimitReader 限制实际读取量；不要把改用 OpenRaw 当成安全限制。

修复动作：归档原样复制优先使用 Writer.Copy

如果任务是把一个 ZIP 成员原样迁移到另一个 ZIP，标准库已经提供 Writer.Copy。官方文档明确说明它直接复制原始形式，绕过解压、重新压缩和内容验证。它比手动拼接 OpenRaw 与 CreateRaw 更直接，也更不容易漏掉头信息。

package main

import (
    "archive/zip"
    "fmt"
    "io"
)

func copyArchive(src io.ReaderAt, srcSize int64, dst io.Writer) error {
    // NewReader 读取现有归档目录，底层 ReaderAt 必须在复制期间保持可用。
    zr, err := zip.NewReader(src, srcSize)
    if err != nil {
        return fmt.Errorf("打开源归档: %w", err)
    }

    zw := zip.NewWriter(dst)
    for _, f := range zr.File {
        // Writer.Copy 复制原始压缩载荷与成员头，不做解压和重新压缩。
        if err := zw.Copy(f); err != nil {
            return fmt.Errorf("复制成员 %q: %w", f.Name, err)
        }
    }

    // Close 会写入目标归档的中央目录，但不会关闭底层 dst。
    if err := zw.Close(); err != nil {
        return fmt.Errorf("完成目标归档: %w", err)
    }
    return nil
}

只有在确实需要自己处理压缩载荷，例如修改成员头后调用 CreateRaw、把压缩字节发送给自定义归档协议，才直接调用 OpenRaw。此时必须把 FileHeader.Method、CRC32、CompressedSize64 和 UncompressedSize64 视为一组相关元数据，不能只搬字节。

防复发：把选择标准写进代码评审清单

• 后续代码要解析、展示或计算业务内容哈希：使用 Open。
• 需要把成员原样放入另一个 ZIP：优先使用 Writer.Copy。
• 确实操作压缩载荷：使用 OpenRaw，并同步维护头信息。
• 使用 Open 时关闭返回的 io.ReadCloser，并检查读到 EOF 时的错误。
• 使用 OpenRaw 时不要误以为无需管理归档生命周期，底层文件仍必须保持打开。
• 测试同时覆盖 Store 与 Deflate，避免 Store 样例掩盖 API 误用。

常见问题

OpenRaw 一定比 Open 快吗？

它跳过了解压，但返回的是另一种数据。只有目标本来就是搬运压缩载荷时，减少解压和重新压缩才有意义；如果最终仍要解析文件内容，后续依然需要按正确算法解压，不能用 OpenRaw 直接替代 Open。

OpenRaw 为什么没有 Close？

它返回 io.Reader，没有创建对外暴露的成员级关闭接口。不过读取器依赖 ZIP 的底层数据源；由 zip.OpenReader 打开的归档仍需调用归档的 Close，并且要等所有成员读取完成后再关。

什么时候用 CreateRaw？

当你已经有与 FileHeader 一致的压缩载荷，并希望把它写入新归档而不重新压缩时使用。普通的归档到归档复制优先考虑 Writer.Copy；要修改正文内容则使用 Open 读取，再用 Create 或 CreateHeader 写入。

只调用 Open 成功，是否说明 CRC 正确？

不能这样判断。调用方应完整读取并检查读取错误，因为校验问题可能在读取过程中或到达 EOF 时出现。

最终判断：把 Open 理解为“给业务代码看的文件内容”，把 OpenRaw 理解为“给归档工具看的压缩载荷”。需要原样迁移时再看 Writer.Copy，这样大多数混用问题会在设计阶段就被排除。