Steam 构建上传与 Depot 配置：从本地版本到可发布 Build

构建上传为什么容易出问题

很多个人开发者在本地测试游戏时很顺利，一到 Steam 后台就开始踩坑：上传后启动失败、玩家下载到旧版本、Demo 覆盖正式版文件、Windows 构建里混入 macOS 资源、分支密码发错、临发售才发现云存档路径不对。原因不是 Steam 上传本身有多神秘，而是开发者没有把“本地可运行版本”转成“平台可分发版本”。

Steam 的构建体系围绕 App、Depot、Build、Package、Branch 等概念运行。你可以把 App 理解为游戏项目，Depot 理解为按平台或内容拆分的文件包，Build 是某次上传生成的版本，Branch 是玩家或测试者能访问的版本通道。理解这些概念后，上架会从“我传了一个文件夹”变成“我知道哪些玩家会下载哪些文件”。

这篇文章面向第一次上传 Steam 构建的独立开发者，重点讲实际流程和检查点。

先整理本地构建目录

上传前不要直接把开发目录丢给 SteamPipe。开发目录里通常有临时文件、调试日志、未压缩素材、编辑器缓存、内部配置、测试存档，甚至密钥。应该为 Steam 发布准备一个干净目录。

推荐结构：

release-builds/
  windows/
    game.exe
    data/
    steam_appid.txt
  macos/
    Game.app
  linux/
    game.x86_64
  notes/
    build-2023-04-12.md

本地导出后，先从这个目录直接运行一次，不要依赖编辑器环境。很多 Unity、Godot、Unreal 项目在编辑器里没问题，导出后会因为路径、插件、权限或缺失运行库失败。独立团队至少要在一台“干净机器”上测试，而不是只在开发机上测试。

Depot 拆分原则

Depot 不要一开始拆得过细。小团队常见的合理拆分是：

如果你的项目只有 Windows 版本，先做好一个 Depot 即可。不要为了“看起来专业”提前建一堆平台 Depot。每多一个 Depot，就多一份上传、测试、权限、包配置和用户支持成本。

拆分 Depot 时要注意共享资源。如果 Windows 和 Linux 使用大部分相同资源，理论上可以拆共享内容，但对个人开发者来说，过早优化会增加维护复杂度。除非游戏体积很大，或者多平台内容差异明显，否则优先选择简单可靠。

启动项必须在 Steam 客户端里测试

本地双击能启动，不代表 Steam 启动项正确。Steam 后台需要配置 Launch Options，告诉客户端在不同平台启动哪个可执行文件、是否带参数、是否需要特定架构。

常见问题包括：

• 可执行文件路径大小写不一致；
• Windows 路径使用了错误斜杠；
• macOS App 包权限或签名问题；
• Linux 可执行文件没有执行权限；
• 启动参数只在开发环境有效；
• 游戏依赖当前工作目录，Steam 启动时路径不同。

每次改启动项后，都应该通过 Steam 客户端安装测试，而不是只在本地文件夹运行。测试步骤可以写成固定清单：

1. 删除本地旧安装；
2. 从 Steam 测试分支重新安装；
3. 点击启动；
4. 新建存档；
5. 进入首个可玩场景；
6. 修改设置并重启；
7. 退出后检查日志；
8. 切换语言或分辨率再启动一次。

这个清单看起来基础，但能抓住很多发售当天才会暴露的问题。

分支管理：默认分支要保守

Steam 分支适合区分公开版本、测试版本、媒体版本和内部验证版本。个人团队至少建议保留三类：

不要把刚上传的 Build 直接推到默认分支。更稳的方式是先上传到 internal，内部测试通过后推 beta，确认没有明显问题再切 default。发售前尤其要保守，因为默认分支的错误会直接影响所有玩家。

分支密码也要管理。不要把内部密码发给大量媒体或玩家，因为它可能长期有效。给创作者或媒体版本时，建议使用专门分支，并在活动结束后更换密码或关闭访问。

Build 记录比版本号更重要

游戏内部版本号、Steam Build ID、Git commit、构建时间、改动内容要能对应起来。否则发售后玩家报 Bug 时，你可能不知道他们到底在玩哪个版本。

建议每次上传后写一条记录：

## Build 2023-04-12-1830

- Git commit: abc1234
- Steam Build ID: 记录后台生成编号
- Branch: internal
- 内容：修复第三关结算崩溃，更新中文教程文本
- 已测：Windows 10、Windows 11、手柄、简体中文、英文
- 未测：Steam Deck、Linux
- 风险：旧存档进入第三关可能仍有异常

这份记录不需要公开，但必须存在。它能帮助你在热修复时判断是否回滚，也能帮助客服回答玩家“我更新后还是崩溃”的问题。

云存档和配置文件不要最后才测

云存档是很多游戏的加分项，但配置错误会造成严重体验问题。常见风险是：路径包含开发机用户名、不同平台路径不一致、把临时缓存当成存档同步、配置文件和存档混在一起、Demo 与正式版存档互相污染。

测试云存档至少要覆盖：

• A 电脑创建存档，退出并等待同步；
• B 电脑登录同账号，下载后继续游玩；
• 修改设置后是否错误覆盖存档；
• 断网游玩后恢复网络是否冲突；
• Demo 存档是否能迁移到正式版；
• 删除本地存档后云端行为是否符合预期。

如果你没有把握，不要为了页面上多一个功能点强行开启。错误的云存档比没有云存档更伤害玩家。

Demo 和正式版要隔离

Demo 常见问题是和正式版共用配置、存档、成就或内容文件，导致玩家试玩后正式版行为异常。更好的做法是从项目层面设计 Demo 边界：

如果 Demo 允许存档继承到正式版，要在页面和游戏内明确说明。继承逻辑也要测试失败情况：正式版内容变化后，旧 Demo 存档能否安全进入？如果不能，就不要承诺。

发售前的构建冻结

建议发售前至少 72 小时进入构建冻结，只接受阻塞级修复。冻结不是停止工作，而是停止无关变化。最后几天最危险的不是已知 Bug，而是“顺手优化”引入的新问题。

冻结期间只做三类事情：

1. 验证当前候选版本；
2. 准备首日热修复分支；
3. 整理已知问题和客服模板。

如果发现严重问题，修复后也要重新跑关键测试。不要因为“只改了一行”就跳过测试。游戏构建常常牵一发动全身，尤其是资源打包、输入、存档和本地化文本。

发布前回滚预案

回滚不是失败，而是发行流程的一部分。发售前应该明确：

• 上一个稳定 Build 是哪个；
• 如何把 default 分支切回稳定版本；
• 回滚后玩家存档是否兼容；
• 公告如何解释；
• 哪些渠道需要同步通知；
• 谁有权限执行回滚。

最糟糕的情况是发售后新版本崩溃，你知道旧版本可用，却没人敢动后台，也没人确定旧版本是否会破坏存档。提前演练一次回滚流程，可以显著降低首发风险。

构建上线最终清单

正式发布前，按这份清单检查：

• 本地发布目录干净，不包含开发缓存、密钥、测试存档；
• Depot 拆分符合实际支持平台，没有多余复杂度；
• 启动项在 Steam 客户端中验证通过；
• default、beta、internal 分支用途清楚；
• Build ID、Git commit、版本号和改动记录对应；
• 存档、配置、语言、分辨率、手柄和音频设置已测试；
• Demo 与正式版存档和配置边界明确；
• 发售前 72 小时进入冻结；
• 已准备热修复分支、回滚方案和已知问题公告。

Steam 构建上传的目标不是“传上去能下载”，而是让每个玩家在正确时间下载正确版本，并且团队知道如何验证、更新和回滚。对独立游戏来说，这套流程越早建立，发售当天就越少把时间浪费在后台救火上。