不能直接用 archive/zip.openreader 做流式预览，因为它会一次性读取并解析整个 zip 中央目录，导致大文件卡顿、内存飙升甚至 oom；真流式需绕过中央目录，逐个解析本地文件头，并用 zip.newreader 配合 io.limitreader 与 size=0 跳过校验，循环 next() 获取文件名，忽略不可靠字段，按 flags & 0x800 判断编码，避免 open() 触发读取，容忍非标 zip 末尾数据。
为什么不能直接用 archive/zip.OpenReader 做流式预览
因为 archive/zip.OpenReader 会一次性读取并解析整个 ZIP 中央目录（central directory），哪怕你只想要前几个文件名。对几百 MB 或 GB 级压缩包，这会导致明显卡顿、内存飙升，甚至 OOM。真正流式读取必须绕过中央目录，从 ZIP 文件头开始逐个解析本地文件头（local file header）。
如何用 archive/zip.NewReader 配合 io.Reader 实现真流式遍历
archive/zip.NewReader 本身不加载中央目录，但它需要知道 ZIP 数据总长度来校验 —— 这在纯流式场景（比如 HTTP body、管道）里往往未知。解决办法是：用 io.LimitReader 或自定义 reader 包裹原始输入，并手动跳过中央目录校验。
- 先用
zip.NewReader创建 reader，传入一个带长度限制的io.Reader（如io.LimitReader(r, limit)） - 调用
reader.Init时传入0作为 size（表示“未知大小”），它会跳过中央目录读取，仅依赖本地文件头解析 - 然后循环调用
reader.Next()，每次只解析下一个文件头和文件名，不读文件内容 - 注意：
reader.FileHeader.Size和UncompressedSize在无中央目录时不可靠，应忽略或仅作参考
zip.FileHeader.Name 编码乱码怎么办
ZIP 规范允许使用 IBM Code Page 437 或 UTF-8（通过通用位标志 bit 11）编码文件名，但 Go 的 archive/zip 默认按 UTF-8 解码，遇到老压缩包就会显示为 字符。不能简单用 golang.org/x/text/encoding 全局转码，因为同一个 ZIP 里可能混用编码。
- 检查
fileHeader.Flags & 0x800是否为非零：若为真，说明该文件头声明了 UTF-8 编码，可安全用 UTF-8 解码 - 否则，尝试用
encoding/ms932（日文）、encoding/ebcdic（部分旧系统）或encoding/unicode/utf16（Windows NTFS 导出 ZIP）——但更稳妥的是 fallback 到 CP437：golang.org/x/text/encoding/ianaindex查IANA.Encoding("ibm-437") - 别依赖
fileHeader.IsEncrypted()判断编码方式，加密标志和编码无关
预览时如何避免解压或读取文件体
只要不调用 zip.File.Open() 或 zip.File.OpenAt()，就不会触发实际数据读取。但要注意两个陷阱：
-
zip.File.Header中的CRC32、CompressedSize等字段，在流式模式下可能为 0 或错误值，不要用于校验或进度计算 - 某些 ZIP 工具（如 macOS 的 Archive Utility）会在末尾添加额外数据（如扩展属性），导致
reader.Next()返回io.EOF后仍有未读字节 —— 应用层需容忍这种“不规范 ZIP”，不要强依赖 EOF 作为结束信号 - 如果需要提前终止（比如只取前 100 个文件名），直接 break 即可；底层 reader 不会继续解析后续字节
流式预览的关键不是“快”，而是“可控内存占用”和“及时响应”。真正难的不是解析 ZIP 结构，而是处理编码歧义、非标 ZIP 格式和用户中断逻辑 —— 这些细节不处理好，前端看到的就是一堆乱码或卡死。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
