tar 归档验收：先核对成员清单，再到隔离目录试解压
压缩包已经生成，并不代表应该归档的文件都在里面，也不代表解压后能按预期使用。路径选择错误、排除规则过宽或打包过程中源文件变化，都可能产生看似正常的归档。本文使用 GNU tar 1.35 语法，针对自己有权读取、已经停止变化的普通资料目录；其他 tar 实现的选项需要核对各自手册。
AI生成概念配图：归档文件先通过清单检查，再进入隔离解压区。仅辅助理解，不代表真实界面或实测结果。
先固定范围和一致性条件
列出归档应包含的顶层目录、关键文件和需要排除的秘密信息，再选择稳定的源目录。正在变化的数据库、上传目录或多文件业务状态，不能仅靠 tar 自动获得一致快照；应先使用应用支持的导出或快照方法。tar 也不是加密工具，私钥和令牌一旦被打进去，会和普通文件一样进入归档。
下面使用新建的私有临时目录存放输出，让归档位于源目录之外，避免把自身再次打包。示例源目录 /srv/site-assets 必须替换，并确认已有读取权限；不要为了方便直接改用 root 打包整个系统。set -e 会在命令失败时停止后续流程，但仍应保留并阅读诊断信息。
set -eu umask 077 work=$(mktemp -d) archive="$work/site-assets.tar.gz" tar -czf "$archive" -C /srv/site-assets . tar -tzf "$archive" > "$work/members.txt" tar -tvzf "$archive"
成员清单检查的是范围，不是全部内容
-C 先切换基准目录，使归档中的成员路径从该目录开始。检查清单时，应确认关键配置和静态资源确实存在，也要检查是否混入缓存、临时文件或敏感材料。详细列表能帮助观察权限、类型和链接目标，但成功列出成员不等于每个文件都符合业务预期，更不是恶意归档的安全认证。
成员名可能包含空格、换行或特殊字符，面向人的列表不应直接当成可执行 shell 脚本，也不要用简单按行拆分去自动删除对应文件。若要做机器可读清单，应选择明确处理文件名边界的流程，并为奇怪文件名准备测试样本。归档成员数量只能作为线索，不能替代关键文件核对。
在源目录不变时比较归档
tar -dzf "$archive" -C /srv/site-assets
--compare 会对归档成员与对应文件系统对象进行比较，报告其能够检查的差异。应同时检查输出与退出状态；如果打包后源文件已经改变，差异不一定说明归档损坏，而是比较时点不同。它也不会自动把源目录中未进入归档的额外文件都认定为遗漏，因此仍需要前面的范围清单。
用普通账户在空目录试解压
mkdir "$work/extracted" tar -xzf "$archive" -C "$work/extracted" \ --no-same-owner --no-same-permissions
这里只对刚刚创建并检查过的归档进行试解压。不要把不可信压缩包直接解到业务目录，也不要仅凭文件扩展名决定如何处理。空目录及其父目录应由可信账户控制，避免其他人同时修改路径。对未知来源还需要更强的隔离和来源审查，列清单与加两个选项并不能消除全部风险。
示例不恢复原始所有者，并让权限遵循当前解压策略，因此适合内容验收，却不代表已完成精确的系统恢复。若交付需要 ACL、扩展属性、稀疏文件或特殊文件类型，应另外制定保存与恢复规则，并在目标环境实测。不要随意加入绝对路径、跟随链接或强制覆盖选项来压过警告。
最后保存能复查的交付证据
在隔离目录中打开关键文件或运行只读验证，确认目录结构和内容可用，再记录归档路径、来源版本、创建时间、清单与校验值。校验值适合检查后续传输是否改变文件，但不能证明最初打包范围正确。归档和这些记录都应按源数据的敏感程度保护，确认交付通过后再按保留策略处理临时产物。
