不能用“高并发容器”构建本地存档核心组件，因其本质是顺序性、事务性强的I/O操作；应封装字节流容器与归档生命周期，通过多实例横向扩展而非单实例多线程并发。

不能用“高并发容器”来构建本地存档核心组件——这个组合本身存在概念错位。本地存档（如 ZIP 打包/解包）本质是顺序性、事务性强的 I/O 操作，不是靠并发提升吞吐的场景。强行引入并发容器（如 ConcurrentHashMap、BlockingQueue）不仅无益，反而破坏归档完整性、引发状态混乱或文件损坏。

归档操作天然不适合高并发

一个 ZIP 文件有严格的格式约束：中央目录必须在末尾、每个 entry 需按顺序写入、CRC 校验依赖完整字节流。若多个线程同时往同一个 zip.Writer 写不同 entry：

• entry 元数据会错位，导致解压失败
• CRC 和压缩流状态无法同步，校验必然失败
• 临时 buffer 冲突或 flush 时机不一致，产生截断文件

真正需要封装的是字节流容器与归档生命周期

高内聚体现在把所有与“本地归档”强相关的逻辑收束到一个类中，而非堆砌并发工具：

• 内部用 bytes.Buffer（Go）或 ByteArrayOutputStream（Java） 作为内存归档容器，但绝不暴露引用
• 所有写入统一走 addEntry(name, content)，该方法自动处理 entry 名字校验、长度限制、重复检测
• archiveTo(path) 是唯一落盘入口，内部用 try-finally 确保 zipWriter.close() 必然执行
• 归档失败时自动清空 buffer，不留下半成品；成功后只提供不可变快照或一次性写入能力

若需支持多任务并行归档，应横向扩展，而非纵向并发

不是让一个组件支持“多线程写同一个 ZIP”，而是让系统能安全启动多个独立归档实例：

• 每个归档任务创建自己的 ArchiveBuilder 实例，互不共享状态
• 通过外部线程池调度多个 builder 并行执行 archiveTo()，各自生成独立 ZIP 文件
• 若需合并多个归档结果，另设 ArchiveMerger 组件，它读取已有 ZIP、解包再重组，仍保持单线程顺序处理

对外接口必须极简，隐藏全部 I/O 细节

使用者只需关心“做什么”，不感知“怎么跑”：

• archiveTo(Path target)：生成一个合法 ZIP 文件
• listEntries()：返回只读的 entry 名称列表（非原始 Map/List）
• extractTo(Path dir)：安全解压，自动过滤 ../ 路径、拒绝超长文件名
• 不提供 getOutputStream()、getBuffer()、setCompressionLevel() 等低阶接口