Layer数据层本质是遵循OCI规范的gzip压缩tar流，需用libarchive逐条解析header、跳过whiteout和虚拟路径，并对原始未压缩tar流计算diffID。
Layer 数据层本质是 tar.gz 压缩的 OCI 文件系统快照
Docker 镜像的 layer 不是 Docker 自研格式，而是遵循 OCI Image Spec 的 tar.gz 归档（带特定白名单路径和元数据约束）。直接用 zlib + libtar 或 C++23 的 <zip></zip>（尚未普及）硬解会失败——因为多数 layer 实际是 **gzip 压缩的 tar 流（not a file）**，且含非 POSIX 路径、扩展属性（xattrs）、whiteout 文件（如 .wh..wh..opq）。你得先解压流，再按 OCI 规范逐条解析 tar header，跳过 control 文件，还原有效文件树。
用 libarchive 比手撸更可靠，但需绕过默认提取行为
libarchive 是少数能原生处理 OCI layer tar 流的 C/C++ 库（支持 ARCHIVE_FORMAT_TAR_PAX_INTERCHANGE 和 xattr 解析）。关键点不是“解压到磁盘”，而是用 archive_read_next_header() 逐条读取 entry，并手动判断是否为有效文件：
- 跳过以
.wh.开头的 whiteout 条目（表示上层删除该路径） - 过滤掉
/dev/、/proc/、/sys/等 runtime 虚拟路径（镜像中不该存在，但某些构建器会误塞） - 检查
archive_entry_pathname()是否含 NUL 或控制字符（非法路径，应丢弃） - 用
archive_entry_xattr_count()提取 SELinux label、capabilites 等，而非忽略
示例关键逻辑：
struct archive *a = archive_read_new();
archive_read_support_filter_gzip(a);
archive_read_support_format_tar(a);
archive_read_open_memory(a, layer_data, layer_size);
struct archive_entry *entry;
while (archive_read_next_header(a, &entry) == ARCHIVE_OK) {
const char *path = archive_entry_pathname(entry);
if (strncmp(path, ".wh.", 4) == 0) continue; // skip whiteout
if (archive_entry_filetype(entry) == AE_IFREG) {
// 处理普通文件：读 content、记录 size、xattrs、mode
}
}
layer diffID 和 chainID 的计算必须用原始未压缩 tar 流
很多人误用解压后的文件内容算 diffID，这是错的。OCI 规定：diffID 是对 **未压缩 tar 流（即 gzip 前的完整字节流）** 做 SHA256。你不能先 gunzip 再 hash——那得到的是 blob digest，不是 diffID。正确做法是用 zlib 的 uncompress() 或 gzstream 边解压边 feeding 到哈希上下文中，或用 zlib 的 inflateInit2(&strm, 16+MAX_WBITS) 手动解码 gzip header 后 raw deflate 流，再 feed 给 SHA256。
立即学习“C++免费学习笔记（深入）”；
- 错误：对解压后目录做
tar -cf - . | sha256sum→ 得到的是 manifest 中的blobSum，不是diffID - 正确：对原始 layer blob（.tar.gz 文件全部字节）解压时，把每个
inflate()输出块实时 update 进 SHA256 ctx -
chainID是上层chainID与当前diffID拼接后 SHA256，注意顺序不可逆
Windows 上解析 Linux layer 要禁用路径自动转换
用 std::filesystem::path 或第三方库处理 layer 内路径时，Windows 默认把 /bin/sh 当成驱动器名报错。必须全程用 raw C string 操作路径，或显式指定 std::filesystem::path 构造时用 std::filesystem::path::generic_string() 而非 string()。另外，Linux layer 中的 symlink 目标路径（如 /bin/bash）在 Windows 上无法 stat()，别试图用 std::filesystem::is_symlink() 验证——它依赖 host OS 语义，而 layer 是跨平台抽象。
真正需要校验的只有：路径长度 ≤ 4096、不包含 \0、首字符为 /、无 Windows 非法字符（:"/\|?*）——这些才是 OCI 层面的有效性边界。
layer 解析最易被忽略的不是算法，而是状态管理：whiteout 如何叠加、hardlink 如何去重、xattr 值是否为空字符串却有 key——这些细节不处理，diffID 就对不上 registry 的 manifest。
