不能用“高并发容器”构建本地存档核心组件，因其本质是顺序性、事务性强的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() 等低阶接口
