是否存在无需因删除内容重建的文件归档格式及引擎实现问询

一、更复杂的可更新归档格式 #

• 7z格式：比zip灵活度高，支持分块存储和固实压缩（但固实模式删除仍需重建）；非固实模式下可标记条目为删除，后续通过整理操作回收空间，不用立即重建整个归档。
• Tar+Zstd组合：Tar本身是纯打包格式，搭配Zstd的可更新压缩特性，能实现部分块的替换，避免全量重建归档。
• SQLite作为归档容器：直接用SQLite存储文件Blob，天然支持增删改查，完全不需要重建归档，事务性和稳定性都有保障，适合频繁修改的场景。
• RAR5格式：支持“快速更新”模式，删除文件时仅修改索引并标记对应数据块为空闲，后续可通过“修复”操作回收空闲空间，无需立刻重建整个归档。

二、自制归档格式的思路点评 #

你说的虚拟缓冲区类+内存块跟踪思路完全可行，这正是很多可更新归档的核心逻辑：

• 用独立的索引区记录所有文件元数据（路径、偏移、大小、状态），同时跟踪空闲块的位置和大小。
• 添加文件时优先填充空闲块，空间不足再追加到归档末尾。
• 删除文件时仅修改索引，标记对应块为空闲，不用移动其他数据。
• 定期执行碎片整理，合并空闲块并移动数据，优化空间利用率。
  需要注意做好崩溃恢复（比如写索引时加校验或事务机制），防止归档损坏。

三、Unreal与Unity的资源归档删除机制 #

Unreal Engine（.pak） #

Unreal的Pak文件默认是只读归档，发布后的Pak一般不会在运行时修改。但编辑器内的临时Pak或可写Pak采用以下逻辑：

• 初始结构类似zip，但索引区支持标记条目为“已删除”，删除操作仅修改索引，不移动数据块。
• 当空闲空间达到阈值或手动触发时，会后台异步执行Pak重组，将有效数据重新打包成新Pak并替换旧文件，不阻塞主线程。
• 运行时动态修改资源通常用Pak补丁包叠加，而非直接修改原Pak，避免破坏只读文件的完整性。

Unity（.unitypackage/AssetBundle） #

• .unitypackage：本质是zip格式，主要用于资源导出/导入，删除操作确实需要重建，但它是设计为一次性传输格式，而非运行时使用。
• AssetBundle：运行时资源包，Unity提供可写AssetBundle模式：
  • 内部采用类似虚拟内存块的管理方式，删除资源时标记对应块为空闲，后续添加资源优先复用空闲块。
  • 当空闲碎片过多时，Unity会在后台执行Bundle压缩优化，将有效数据重新打包以回收空闲空间。
  • 对于频繁更新的场景，Unity推荐用Addressables框架，通过增量补丁包更新资源，避免直接修改原Bundle。

内容的提问来源于stack exchange，提问作者Zebrafish