Steam 发布、Playtest 与更新

原理：包、构建与渠道分离

• Depot：玩家实际下载的内容集合，可按平台、语言或 DLC 拆分。
• Build：某次上传生成的不可变构建身份；发布时把构建分配到分支。
• Branch：玩家或测试者看到的版本通道，适合区分默认、beta、内部测试。
• Playtest：用受控测试入口收集真实玩家反馈，可与正式商店页面和发行节奏分离。

因此，更新应记录“哪个提交生成了哪个 build，哪个分支在何时指向它”，而不是只记录“今天上传了新版本”。

应用：从候选包到渐进发布

flowchart LR
    A["候选构建"] --> B["上传 Depot"]
    B --> C["内部分支"]
    C --> D["Steam Playtest"]
    D --> E{"验收与指标"}
    E -->|"通过"| F["默认分支"]
    E -->|"失败"| G["回退到已知构建"]
    G --> C

建议流程：

1. 在 CI 生成平台包、版本清单、符号文件和变更说明。
2. 用 SteamCMD/Steamworks 上传到专用构建，先指向内部密码分支。
3. 对启动、安装、更新、存档兼容、网络连接和 DLC/语言组合做 Smoke。
4. 通过 Playtest 或 beta 分支扩大样本；记录版本与反馈关联。
5. 先发布小范围更新，再观察崩溃率、启动成功率、关键漏斗和客服信号。
6. 预先保留上一个已知良好 build；出现阻断问题时回退分支指向，而不是临时覆盖文件。

发布前检查清单

• 商店页面、年龄/地区限制、依赖和第三方声明已完成。
• 默认分支与测试分支的 Depot、启动参数、存档迁移策略一致且有意差异。
• Windows/Linux/macOS 等目标包可在干净环境安装、启动、更新和卸载。
• 更新后旧存档、配置和网络协议的兼容策略已验证。
• 版本号、构建号、崩溃符号和客服可见版本一致。
• 发布窗口、值班 owner、状态页、回滚构建和沟通模板已准备。

取舍与常见坑

• 把 Playtest 当软发布：Playtest 是受控反馈渠道，不自动等同于正式发行验收。
• 只验证首次安装：补丁、断点续传、磁盘空间不足和旧版本迁移更容易暴露问题。
• 更新不可回滚：没有保留已知良好 build 时，修复会被迫在生产线上继续冒险。
• 分支过多：通道越多，内容和配置漂移越大；每个分支都要有明确受众和生命周期。
• 忽视 CDN/区域差异：发布后需观察区域下载失败、更新耗时和带宽成本，而不仅是本地成功。

Steam Quick Start 是官方路线入口；具体执行应继续阅读 Steamworks 的 Builds、Uploading、Playtest 和 Updates 文档，不要把入口页误称为完整课程。