std::filesystem 仅支持目录遍历，无法满足热更新所需的资源校验、依赖管理与增量更新能力；裸文件无元数据、哈希及引用关系，导致无法实现按需解包与版本控制。
为什么不能直接用 std::filesystem 遍历打包资源
因为热更新要求资源可独立加载、版本可控、运行时能按需解包，而裸目录结构无法提供校验、依赖管理和增量更新能力。你遍历出来的 .png 或 .json 文件，没元数据、没哈希、没引用关系，上线后改一张图就得全量重发包。
实操建议：
- 必须为每个资源生成唯一标识：推荐用
SHA256（不是MD5），计算原始文件内容（非路径名） - 资源元数据要单独序列化进包头，字段至少包含：
path、hash、size、dependencies（字符串 vector）、type（如"texture"/"script"） - 避免在打包阶段做资源转换（如压缩纹理），那属于构建管线前置步骤；打包器只做「归档+索引」
如何让 C++ 运行时快速定位并解压单个资源
不能把整个 .bundle 当 zip 解压到磁盘——IO 慢、脏文件多、无权限控制。正确做法是内存映射 + 自定义索引区（类似 Unity 的 AssetBundle header）。
实操建议：
- Bundle 文件格式 = [
header_size(uint32)] + [header_bytes] + [payload]；header 用flatbuffers或简易二进制结构（4 字节 magic + 4 字节 version + 4 字节 entry_count + N * entry），entry 含 offset/size/hash/path - 加载 bundle 时只
mmapheader 区域（通常 memcpy 对应 payload 片段到内存 - 不要自己实现压缩流解码逻辑；用
zstd（比 zlib 快且压缩率好），但仅对 payload 整体压缩，header 必须明文可随机访问
AssetBundle::LoadAsset("ui/button.png") 怎么避免重复解码和类型擦除开销
这个调用背后如果每次都要查 hash 表 + new 分配 + dynamic_cast，热更频繁时帧率会抖动。核心矛盾是：既要支持任意资源类型，又不能牺牲性能。
实操建议：
- 资源加载结果不返回裸指针，而是
AssetHandle（含引用计数 + 类型 tag + 内存地址），构造时只做一次static_cast，后续operator->()直接返回 - 解码缓存用两级 key：第一级是
bundle_path + asset_hash（确保内容一致才复用），第二级是type_id（同一份二进制可被解释为Texture2D或SpriteAtlas） - 禁止在
LoadAsset中触发磁盘 IO；所有 IO 必须在LoadBundle阶段完成，LoadAsset应该是纯内存操作
热更新差分包（delta patch）怎么生成才不崩客户端
用 bsdiff 直接打两个完整 bundle 的二进制差分？不行。bundle 内部资源顺序稍有变化（比如加了个新资源），整个 payload 偏移全乱，差分体积接近全量。
实操建议：
- 差分单位必须是「资源粒度」，不是文件或 bundle 粒度；先比对新旧 bundle 的资源哈希集合，找出新增/删除/变更项
- 变更项的 diff 用
zstd的ZSTD_compressSeeded：以旧资源数据为字典，压缩新资源数据，小资源（如.json）能压到几十字节 - 差分包本身也要带 bundle header 结构，客户端用同一套 loader 加载，只是 payload 解析逻辑分支为「直接读」或「字典解压」
最容易被忽略的是资源路径规范化：Windows 下 "Textures\icon.png" 和 macOS 下 "Textures/icon.png" 必须统一转成 "Textures/icon.png" 再参与哈希与比对，否则同个文件会被当成两个不同资源。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
