Steam 包、默认分支与可购买状态：上架前别让玩家下错版本

玩家不会看到你的本地文件夹

个人开发者经常把注意力放在“我上传了正确构建”，却忽略另一个问题：玩家购买后到底能下载到什么。Steam 上的可购买状态，不只是构建上传成功，还和包、Depot、平台、默认分支、价格、商店状态共同有关。后台里每个环节看起来都独立，最终却会组合成玩家的实际体验。

最典型的问题是：测试分支是新版本，默认分支还是旧版本；Windows Depot 正确，macOS Depot 漏了文件；内部测试包能下载，商店购买包没有包含正确 Depot；发售前用开发者账号能启动，普通购买账号却拿不到内容。玩家不会关心你后台哪里配置错，他只会认为游戏无法下载或版本不对。

上架前必须做一次“玩家视角购买和下载审计”。不是看你传了什么，而是看一个普通玩家购买后拿到什么。

先理解包、Depot 和分支的关系

可以用一个简单模型理解：

个人开发者不需要把所有后台概念研究成专家，但要知道它们会一起影响玩家下载。尤其是默认分支和商店包，发售前必须重点检查。

给不同用途分清包

Steamworks 中可能有开发者包、测试包、商店包、Key 包等。小团队最容易把这些混在一起：用开发者包测试通过，就以为玩家也能下载；用测试 Key 打开没问题，就以为商店购买没问题。

建议把包按用途记录：

每个包都写进发行文档。发售前，不要只说“这个 Key 能玩”，要说“press-preview 包绑定 release-candidate 分支，商店销售包绑定 default 分支”。这样排查问题才有方向。

默认分支要像正式版本一样管理

很多开发者喜欢把最新构建放在测试分支，把 default 留到最后才切换。这个流程可以，但必须有明确切换时间和验证步骤。默认分支一旦面向玩家，就不能再当临时通道。

默认分支检查：

• 当前指向哪个 Build；
• Build 号是否和发售候选版一致；
• Windows/macOS/Linux Depot 是否都包含；
• 是否移除了调试菜单；
• 是否包含正确语言文件；
• 是否能从普通账号下载；
• 是否和商店页承诺一致；
• 是否保留上一稳定 Build 以便回滚。

如果你需要保留测试分支，给它清楚命名，例如 internal-test、rc-2022-03，不要用 new、test2、final 这种无法长期理解的名字。

平台 Depot 要逐个平台下载验证

支持多个平台时，不要只检查 Windows。每个平台都要从 Steam 客户端下载安装一次。尤其是 macOS 和 Linux，文件权限、启动脚本、大小写路径、依赖库都可能出问题。

平台验证表：

如果某个平台尚未准备好，不要在商店页勾选或公开承诺。先发布稳定平台，再补平台，比三平台同时翻车更好。

用普通账号做购买后验证

发售前最有效的检查，是模拟普通玩家。开发者账号往往拥有额外权限，无法代表真实购买用户。你需要一个没有开发权限的测试账号，通过 Key 或测试包验证实际下载。

验证流程：

1. 确认测试账号没有后台权限；
2. 领取对应 Key 或通过测试包获得访问；
3. 从 Steam 客户端安装；
4. 检查库中显示名称、图标和状态；
5. 启动游戏；
6. 查看版本号；
7. 完成前 10 分钟流程；
8. 卸载重装；
9. 检查更新是否正常。

如果测试账号拿到的版本和开发者账号不同，说明包或分支配置需要检查。不要在这个问题上凭感觉。

Demo 和正式版必须隔离

Demo 和正式版的包、存档、商店链接和结尾引导都要分清。常见问题包括 Demo 包含正式版未公开内容、正式版读取 Demo 测试存档后崩溃、Demo 结尾链接指向错误页面、Demo 的语言栏和正式版不同却没有说明。

隔离清单：

• Demo App 与主游戏 App 关系清楚；
• Demo 只包含试玩内容；
• Demo 存档路径和正式版策略明确；
• Demo 结尾引导回主游戏商店页；
• Demo 分支不影响正式版 default；
• Demo 页面写清内容边界；
• Demo Key 和正式版 Key 不混用。

如果 Demo 存档能继承，要测试继承；如果不能继承，要提前说明。不要让玩家自己猜。

价格可见不等于购买链路完成

价格设置完成后，还要确认可购买链路和包内容一致。尤其是首发折扣、地区价格、发售时间和商店包状态，需要在发布前统一检查。

检查项：

• 商店页显示价格是否正确；
• 发售折扣是否按计划；
• 地区价格是否已保存；
• 商店包是否可购买；
• 购买后获得的 Depot 是否正确；
• 退款和客服入口是否正常；
• 发售时间是否与公告一致。

价格和包配置都属于高风险操作，最好由同一个负责人或两人交叉检查。小团队也可以做“读表确认”：一个人读检查项，一个人看后台。

发售前包配置审计表

最终审计表：

审计表要保存到发行文档，不要只在脑子里过一遍。发售后如果玩家说下载内容不对，你可以快速定位是包、分支还是构建。

常见事故和排查顺序

包和分支问题出现时，不要立刻重新上传构建。先按顺序排查，否则可能把正确构建覆盖成错误构建。

排查时记录每一步：当前包、当前分支、当前 Build、测试账号结果。不要只在后台点来点去。Steam 后台配置一多，人的短期记忆很快不可靠。

给测试者发 Key 前先确认包

外部测试者拿到的 Key 应该代表你希望他们测试的版本。如果你希望他们测发售候选版，就不要给他们一个仍绑定旧测试分支的包。发 Key 前写清：

• Key 批次名称；
• 对应包；
• 对应分支；
• 测试版本号；
• 是否会自动更新；
• 测试结束后是否失效。

这样测试反馈才有意义。否则测试者说“第二关卡死”，你还要先确认他到底玩的哪个包和哪个分支。

发行质量来自玩家视角

Steam 后台配置很多，但最终只有一个问题：玩家付费后是否拿到了正确版本。个人开发者最容易在开发者视角里测试通过，却忽略普通账号、普通包和默认分支。上架前做一次包和分支审计，能避免非常尴尬的首发事故。

不要等发售当天才发现玩家下错版本。把包、Depot、Build、Branch 和商店状态写清楚，用普通账号验证下载，用表格记录结果。这样即使后续做 Demo、DLC、测试分支和补丁，也不会在后台配置里迷路。