Steam的Build与Manifest：一份记录内容快照，一份列出文件

游戏开发交接提到“这次的build已经有manifest”，其中并非两个同义词。Steamworks的Builds文档分别定义了它们：Build是上传内容的结果，可以包含一个或多个depot，并表示这些depot在某一时点的内容；Manifest则是depot build所含文件的清单及相关元数据。[1]

先看Build所回答的问题。它把内容与某一时间状态联系起来，而不只是给任意文件起个新名字。文档还说明，depot的新构建可以修改或移除旧构建包含的文件，也可以增加文件。因此，“新build”不意味着其中每个文件都是新加入的，更不能仅凭版本名称推断改动了哪些内容。

Manifest进一步走到文件层。来源列举的元数据包括文件大小、SHA1哈希和一组flags。清单不仅告诉读者有哪些文件，还包含描述这些文件的字段。把清单当作一段更新宣传，或者把一个文件名当作整份清单，都失去了原文所说的具体对象。

可以用一个没有实际项目数据的交接例子理解：一份说明记录“某时点的内容包含哪些depot”，另一份记录“其中某个depot build列出了哪些文件”。前者不能独自代替后者逐项给出文件信息；后者也不能不加范围地被描述成整个应用的一切资料。此例没有列造文件、计算哈希或验证上传成功。

“文件清单已经存在”与“玩家已经收到内容”，同样属于不同问题。文档在定义之后另设Managing Uploaded Builds等章节，讨论构建的管理与生效。定义一份清单的内容，并不会自动说明某构建已经向何人交付。本文不采用分支操作、授权步骤或发布安排，只保留内容记录与发布结果需要分别证明的边界。

对项目资料的阅读，Build的时点、所包含的depot，以及Manifest所针对的depot build，能帮助明确一份记录覆盖哪部分内容。若没有文件层证据，就如实说尚未核对；若没有真实发布结果，也不把结构说明写成发行已完成。这是依据两个定义作出的交接分析，不是Steam要求的固定表格。

本文仅采用本次读取的Steamworks Builds及Manifests定义，页面未确认首次发布日期。没有使用SDK命令、上传或修改游戏，也不作发行许可、合同或文件完整性验收。读准这两个层级后，一句“版本有清单”才开始具有可追溯的范围。

资料来源：[1] Valve，Steamworks Documentation：Builds。