3. 归档包结构
归档包是元数据规范的物理载体。理解其内部结构、组织原则与格式特性，是正确封装审查意见与变更记录的前提。本节从三个层次展开：组成要素（包内有什么）、组织原则（如何摆放）、格式对比（选哪种容器）。
3.1 归档包组成要素
一个标准归档包由以下四类要素构成，缺一不可：
| 要素类别 | 说明 | 示例 |
|---|---|---|
| 元数据文件 | 描述包自身结构、内容清单、校验信息的核心文件 | metadata.xml、manifest.json |
| 审查意见记录 | 按规范格式存储的审查意见正文及属性 | reviews/ 目录下的 .xml 或 .json |
| 变更记录 | 按时间线或版本组织的变更日志 | changelog/ 目录下的 .md 或 .csv |
| 附件与引用 | 审查中引用的截图、日志、补丁等辅助文件 | attachments/ 目录下的 .png、.log |
要点：元数据文件必须位于归档包根目录，且命名固定。审查意见与变更记录应分目录存放，避免与附件混杂。
3.2 包内文件组织原则
文件组织遵循三条核心原则，确保包内结构可预测、可扩展、可验证：
- 根目录扁平化：元数据文件（如
metadata.xml、manifest.sha256）直接放在根目录，不超过 5 个文件。 - 内容目录分层：审查意见、变更记录、附件分别放入
reviews/、changelog/、attachments/子目录，禁止跨目录引用。 - 命名可排序：文件命名采用
YYYYMMDD_HHMMSS_序列号.扩展名格式，支持按时间排序与去重。
推荐结构示例：
archive-package/
├── metadata.xml # 包元数据（必需）
├── manifest.json # 文件清单与校验值（必需）
├── reviews/ # 审查意见目录
│ ├── 20250301_143000_001.xml
│ ├── 20250301_143000_002.xml
│ └── 20250302_090000_001.xml
├── changelog/ # 变更记录目录
│ ├── 20250301_changelog.md
│ └── 20250302_changelog.md
└── attachments/ # 附件目录
├── screenshot_001.png
└── debug_log_001.txt3.3 常见归档格式对比
ZIP、TAR、GZIP 是三种最常用的归档格式。下表从压缩能力、元数据保留、跨平台兼容性三个维度进行对比：
| 特性 | ZIP | TAR | GZIP |
|---|---|---|---|
| 压缩方式 | 内置 DEFLATE 压缩 | 不压缩，仅打包 | 仅压缩单个文件流 |
| 目录结构保留 | 原生支持 | 原生支持 | 不支持（需配合 TAR） |
| 文件权限保留 | 有限（需扩展属性） | 完整保留 Unix 权限 | 不保留 |
| 跨平台兼容性 | Windows/macOS/Linux 原生支持 | Linux/macOS 原生，Windows 需工具 | 全平台支持 |
| 随机访问 | 支持（目录索引在尾部） | 支持（顺序读取） | 不支持（需解压全部） |
| 推荐场景 | 跨平台分发、交互归档 | Linux 服务端、保留权限 | 日志压缩、单文件压缩 |
注意：GZIP 本身不是归档格式，它只压缩单个数据流。若要归档目录结构，必须先用 TAR 打包成
.tar 文件，再压缩为 .tar.gz。ZIP 则同时完成打包与压缩，适合作为审查意见归档包的默认格式。
3.4 归档格式选择决策流程
以下 SVG 流程图展示了根据场景选择归档格式的决策路径：
3.5 格式选择建议
针对审查意见与变更记录的归档场景，给出以下具体建议：
- 默认首选 ZIP：跨平台兼容性好，支持目录结构与随机访问，适合与外部审查系统交换数据。
- Linux 自动化流水线用 TAR：保留文件权限与时间戳，适合 CI/CD 环境中的归档与校验。
- 日志或单文件压缩用 GZIP：变更记录导出为单个 CSV 或 JSON 文件时，直接使用 GZIP 压缩。
- 组合格式 .tar.gz：当需要同时保留目录结构与高压缩率时，使用 TAR 打包后 GZIP 压缩。
实践建议：在元数据规范中明确指定归档格式（如
application/zip），并在 metadata.xml 的 <format> 字段中记录，便于解析器自动识别。