怎么做一次发布前检查How to run a pre-release check

这篇解决什么：项目从「自己机器上能玩」到「交到别人手里」之间的最后一次系统性核对。适用于要对外分享（哪怕只发给几个朋友）的构建；纯本地练习不算发布，可以跳过。开发机运行成功不等于发布完成（阶段背景见 S5 · 导出与发布）。

What this guide solves: the last systematic pass between "it plays on my machine" and "someone else receives it". It applies to any build you share outside your own machine — even to a few friends; local-only practice is not a release and can skip this. Running fine on the dev machine is not shipping (stage background: S5 · Ship it).

适用条件

• ✅ 你已经从引擎导出过至少一个成品包（不是编辑器里的运行）
• ✅ 目标平台已定（网页 / 桌面 / 手机至少一个）
• ⚠ 不适用：还没跑通核心循环的项目 —— 先回 S2 · 核心循环
• ⚠ 不适用：想借这轮检查判断「好不好玩」—— 发布前检查只能证明「能打开、能操作、不丢存档」

When this applies

• ✅ You have exported at least one finished package from the engine (not just a run inside the editor)
• ✅ The target platform is decided (web / desktop / mobile, at least one)
• ⚠ Not for projects whose core loop is not running yet — back to S2 · The core loop
• ⚠ Not a "is it fun" test — a pre-release check only proves "it opens, it responds, saves survive"

步骤

1. 冻结版本。 写下三件事：引擎版本、导出模板版本、这一版内容的编号（例如 0.1.0，示例编号为虚构约定）。此后改动都要重新走一遍本清单。

2. 从头导一次包。 用导出预设重新导出，不要复用开发目录里的旧文件 —— 需要逐平台配置导出预设的原因，Godot 官方导出文档写了预设的创建方式（见文末核验表）。

3. 干净环境打开。 换一台没装过开发工具的机器，或浏览器新建一个无痕配置档，再打开这个包。开发机上「能跑」常常是因为残留的本地文件。

4. 目标设备各过一遍。 网页版：在目标浏览器里测加载、声音、触控（若用鼠标）。引擎对浏览器有硬性要求时按官方文档核对 —— 例如 Godot 的 Web 导出文档写明 Web 构建要求浏览器支持 WebAssembly 与 WebGL 2.0（核验表）。

5. 行为三件套：存档、断网、音量。 刷新后进度是否还在、断网是崩溃还是提示、首次进入是否带声音（逐项见 存档与离线行为）。

6. 素材归位。 每个进包的素材在台账里有对应行、「待确认」列为空（做法见 怎么做一份素材与许可台账）。

7. 写失败归属清单。 每条失败记：现象 → 复现步骤 → 初步归属层（代码 / 素材 / 平台设置 / 未知）。归属「未知」的条目不许删。

The steps

1. Freeze the versions. Write down three things: engine version, export-template version, and this build's content number (say 0.1.0 — invented for the example). Anything changed after this re-runs the whole list.

2. Re-export from scratch. Export again through the export presets; do not reuse leftovers from the dev folder. Godot's official export docs show how an export preset is created (table at the end).

3. Open in a clean environment. Use a machine without the dev tools, or a fresh browser profile. "Works on my machine" often means stray local files.

4. Pass each target device. Web: test load, audio and input in the target browsers. Where an engine has hard browser requirements, check the official docs — Godot's web-export docs state that web builds require WebAssembly and WebGL 2.0 support in the browser (see the table).

5. The behaviour trio: saves, offline, audio. Progress after refresh, crash or graceful message without network, sound on first entry (details: Saves and offline behaviour).

6. Assets in place. Every packaged asset has a ledger row and the "unconfirmed" column is empty (method: How to build an asset and licence ledger).

7. Write the failure-attribution list. For each failure: symptom → repro steps → likely layer (code / asset / platform setting / unknown). Nobody deletes an "unknown".

一个可走查的例子

⚠ 包体大小、机型与现象全部是虚构示例，不是实测数字。

• 输入：一个网页解谜游戏的导出包（虚构：约 9.8 MB，含入口 HTML 与数据文件），目标：桌面浏览器 + 一台旧的入门级安卓机。
• 处理：按清单走 —— 干净浏览器档打开桌面版正常；旧安卓机上页面白屏，无声音；打开浏览器控制台，出现与图形初始化相关的报错（虚构现象）。
• 结果判断：白屏且报错指向图形层，初步归属为「平台能力不足」而不是游戏逻辑 bug —— 该设备不满足目标浏览器所需的图形能力。判定为「失败，归属平台/设备」并记录复现步骤。
• 失败后下一步：二选一并重跑清单：① 在发布页明确写最低设备/浏览器要求；② 降低图形需求做兼容版。不选「假装没测到」。

A walk-through example

⚠ The package size, the device and the symptoms are all a fictitious example — no measured numbers.

• Input: an exported web puzzle game (invented: about 9.8 MB, entry HTML plus data files), targets: desktop browsers and one old budget Android phone.
• Processing: walk the list — clean browser profile on desktop: fine; the old phone: white screen, no audio; the browser console shows a graphics-initialisation error (invented symptom).
• Result: white screen plus a graphics-layer error is read as "device capability shortfall", not a game-logic bug — the device does not meet what the web build needs from the browser. Verdict: fail, attributed to platform/device, with repro steps recorded.
• After the failure: pick one and re-run the list — ① state the minimum device/browser requirements on the release page; ② cut the graphics demand into a compatible build. "Pretend we never tested it" is not an option.

失败分支

Failure branches

下一步

• 检查通过后先发一个粗糙但能玩的版本收集反馈：先发极简版
• 平台选择与导出边界的整体判断：Web 导出可行性

Next steps

• After the check passes, ship a rough but playable cut for feedback: Ship the smallest version first
• Platform choice and export boundaries: Web export feasibility