导出预设：Godot 跨平台工程的中枢

Godot 的导出预设（Export Preset）系统是跨平台工程的中枢。它把每个目标平台的复杂配置封装为可视化模板，让开发者不必记忆命令行参数，在编辑器里即可完成跨平台构建。

预设结构的核心元素

一个完整的导出预设包含以下字段：

• 平台目标：Windows / Linux / macOS / Android / iOS / Web。
• 包含/排除过滤器：哪些资源打入包、哪些排除。
• 加密与签名：PCK 加密、平台代码签名配置。
• 启动画面与图标：各分辨率图标资源指定。
• 平台专属配置：iOS 的 Bundle ID、Android 的 Gradle 配置等。

预设复用：团队协作的工程基础

对于团队项目，导出预设文件应纳入版本控制：每个开发者使用同一份预设，避免"在我电脑上能导出"的问题。建议在 Git 中明确追踪 `export_presets.cfg` 文件。

Steam 发行全流程：从 Godot 到商店页

Steam 是独立游戏 PC 平台发行的主要渠道。Godot 项目的 Steam 发行流程相对成熟，核心障碍不在 Godot 端，而在 Steamworks 集成。

Step 1：Steamworks 注册与 Steamworks SDK

注册 Steamworks 合作伙伴账户（约 100 USD 一次性费用）后，获取 AppID。下载 Steamworks SDK（独立游戏开发者通常使用 GodotSteam 插件作为绑定层）。

Step 2：GodotSteam 集成

GodotSteam 是社区驱动的 Steamworks 非官方绑定（基于 GDExtension），覆盖成就、排行榜、云存档、创意工坊、语音、DLC 等核心 Steamworks API。集成步骤：

• 下载 GodotSteam 资产库版本对应的 release。
• 将 GDExtension 文件放入项目。
• 在 Project Settings → Steam 配置 AppID 与 SDK 路径。
• 在 AutoLoad 中初始化 Steam API。

Step 3：构建与上传

使用 Godot 编辑器构建 Windows / macOS / Linux 三个版本。上传至 Steamworks 合作伙伴后台的"构建"标签页，设置分支（默认 / 测试 / beta），提交审核。

Step 4：商店页配置

Steam 商店页需要：宣传视频、截图、描述、标签、价格、地区可用性、上线日期。商店页通常在游戏上线前 1-3 个月开放曝光，建议提前准备。

Step 5：测试与发布

利用 Steam 分支（SteamBranch）功能发布测试版，让 wishlist 用户试玩，收集反馈、修复问题，最终发布正式版。

iOS 导出与 App Store 上架

iOS 是 Godot 跨平台流程中最复杂、最容易踩坑的环节。Godot 4 在 iOS 支持上经历了历史性反复：Godot 3 时代稳定支持，Godot 4 初期 .NET 6 迁移导致 iOS 暂时性中断，现已恢复。

前置准备：Apple 开发者账户

需要 Apple Developer Program 会员资格（个人 99 USD/年），获取：

• 开发证书（Development Certificate）。
• 发布证书（Distribution Certificate）。
• App ID（与项目 Bundle Identifier 对应）。
• Provisioning Profile（开发 / 发布 / Ad Hoc 三种）。

导出流程

1. 在 Godot 编辑器中创建 iOS 导出预设。
2. 配置 Bundle Identifier 与签名信息。
3. 点击导出，生成 Xcode 项目（Godot 不会直接生成 IPA）。
4. 用 Xcode 打开项目，选择目标设备 / 模拟器。
5. 执行 Archive → Distribute App → App Store Connect。

App Store 审核注意事项

Apple 审核对游戏类应用相对友好，但仍需注意：

• 应用内购买必须使用 IAP，不能绕过。
• 隐私政策 URL 必须可访问。
• 儿童类应用有额外限制。
• 首次提交审核通常需要 1-3 天，不要卡上线日期。

Android 导出与 Google Play 上架

Android 导出在 Godot 4 中相对稳定，主要工程难点是 Gradle 定制与多架构构建。

前置准备

• Java JDK 17+（Godot 4 要求）。
• Android SDK 与 Build Tools。
• Android NDK（用于 GDExtension 编译）。
• Gradle（Godot 4 自带 Gradle Wrapper）。
• Keystore 签名文件（应用签名）。

导出流程

1. 在 Godot 中创建 Android 导出预设，配置包名与签名。
2. 选择目标架构（推荐 arm64-v8a + armeabi-v7a 双架构）。
3. 执行导出，生成 APK 或 AAB（推荐 AAB 上传 Google Play）。

Google Play 审核

Google Play 审核比 App Store 宽松，通常几个小时即可通过。但需注意：

• 目标 API 等级要求（每年更新）。
• 64 位架构要求（2026 年起 32 位应用不再接受）。
• 权限声明必须明确，运行时申请敏感权限需要用户确认。
• 隐私政策与数据安全声明。

Gradle 定制：第三方 SDK 集成的关键

对于需要集成 Firebase、Admob、统计 SDK 的项目，Godot 4 允许通过自定义 Gradle 模板注入配置：

• 在 Godot 项目中创建 `android/plugins/` 目录。
• 添加 `.gdap` 配置文件描述插件。
• 在 `android/build.gradle` 中添加 Maven 仓库与依赖。
• 导出时 Gradle 自动包含插件。

Web 平台导出与 SharedArrayBuffer 兼容性

Web 平台导出是 Godot 的战略性优势——零安装、即点即玩、跨设备兼容性。但工程上有一系列"看不见的坑"需要规避。

SharedArrayBuffer 与跨域隔离

Godot 4 的 Web 导出需要使用 SharedArrayBuffer（用于多线程），而 SharedArrayBuffer 只能在跨域隔离（Cross-Origin Isolated）的页面中使用。这意味着部署 Web 版本的游戏必须配置两个 HTTP 响应头：

• Cross-Origin-Opener-Policy: same-origin
• Cross-Origin-Embedder-Policy: require-corp

这两个头在大多数静态托管服务（itch.io、Vercel、Netlify）上需要手动配置，遗漏将导致游戏完全无法运行。

Godot 4 Web 导出的可选策略

对于希望"无 SharedArrayBuffer 也能跑"的场景，Godot 4 提供"线程模式"选项：

• SharedArrayBuffer 模式：多线程，性能最佳，需要跨域隔离配置。
• 无 SharedArrayBuffer 模式：单线程，兼容性更好，性能略低。

对 itch.io 等无法配置 COOP/COEP 头的平台，必须选择无 SharedArrayBuffer 模式。

常见托管平台的部署

• itch.io：支持 HTML5 游戏直接上传，无法配置 SharedArrayBuffer 头，需用兼容模式。
• Newgrounds：类似 itch.io。
• 自建 Web 服务器：完全可控，可启用 SharedArrayBuffer 模式。
• GitHub Pages / Vercel / Netlify：通过 `_headers` 文件或 CDN 配置响应头。

主机平台：W4 Games 商业合作路径

主机平台（Nintendo Switch / PlayStation / Xbox）是 Godot 跨平台战略中最具争议的领域。

现状：官方支持缺失

Godot 引擎本体不提供 PS5、Xbox Series、Switch 的官方导出支持。这是历史原因：主机 SDK 都是 NDA 下的闭源商业协议，Godot 基金会的法律与资源结构无法直接对接。

W4 Games：商业合作填补空白

W4 Games 是 Godot 社区的官方商业合作伙伴，由 Godot 联合创始人 Juan Linietsky 等核心贡献者创立，提供主机平台移植与认证服务。其商业模式是收取一次性移植费用 + 持续技术支持，不抽成游戏收入。

W4 Games 的服务范围：

• Nintendo Switch 移植与认证。
• PlayStation 4/5 移植与认证。
• Xbox Series X|S 移植与认证。
• 技术咨询与持续支持。

主机移植的成本与时间估算

基于 Xmohe 调研的 3 款独立游戏主机移植项目：

• Switch 移植：6-12 周，3-5 万 USD（不含认证费）。
• PS5 移植：4-8 周，3-6 万 USD。
• Xbox 移植：3-6 周，2-4 万 USD。

对销量预期明确的独立游戏，主机移植的投入产出比通常是正向的；对销量不确定的项目，建议先验证 PC / 移动 / Web 平台。

初级用户路径：从桌面导出开始

对于 Godot 初学者，Xmohe 推荐的导出学习路径：

1. 第一步：完成 Windows / Linux / macOS 桌面导出。这是最简化的导出流程，没有签名、没有审核。
2. 第二步：尝试 itch.io Web 部署。选择无 SharedArrayBuffer 模式，用 itch.io 的"嵌入构建"功能。
3. 第三步：尝试 Android 导出。配置好 JDK 与 Android SDK 后，侧载测试。
4. 第四步：研究 iOS 导出。需要 Mac 电脑，但 Godot 4 导出配置已经简化。

主机平台是最后考虑的，通常需要 W4 Games 商业合作。

中级用户路径：多平台分发的工程架构

对于 3+ 平台同步发行的中型项目，Xmohe 推荐的工程架构：

架构原则：单代码库 + 平台分支 + 自动化构建

• 单代码库：所有平台共享同一份 GDScript / C# 代码，平台差异通过条件编译或特性检测处理。
• 平台分支：导出预设按平台分组管理，每个平台独立的构建参数。
• 自动化构建：使用 GitHub Actions / GitLab CI / Jenkins 自动构建，每次提交触发多平台构建。

CI/CD 配置模板

Xmohe 推荐的 GitHub Actions 配置：

• 在 `ubuntu-latest` 上构建 Linux / Web / Android。
• 在 `macos-latest` 上构建 macOS / iOS（需要签名密钥）。
• 在 `windows-latest` 上构建 Windows。

平台特性检测 vs 条件编译

Godot 不直接支持 `#ifdef PLATFORM_WINDOWS` 预处理，但有两种替代方案：

• 特性检测：`OS.get_name()` 返回平台名，运行时分支。
• 数据驱动：不同平台用不同 DataAsset / DataTable，引擎加载时自动选择。

推荐优先使用数据驱动方案，它让"平台差异"成为可配置项而非硬编码。

争议地带：开源精神与商业模式的张力

Godot 的主机支持策略在社区中引发了持续争议。

争议两方观点

批评方观点：W4 Games 收费提供主机导出支持，与 Godot "完全开源、零费用"的形象存在张力。部分社区成员担心这会让 Godot 成为"半开源引擎"，主机支持被商业实体垄断。

支持方观点：主机 SDK 本身是闭源商业协议，任何开源引擎在主机支持上都需要商业层介入。W4 Games 由 Godot 核心贡献者创立，其商业模式不抽成游戏收入，已经是最优解。

Xmohe 的客观判断

这个争议在 2026 年仍未有定论，但事实是：

• W4 Games 是 Godot 社区目前唯一可靠的主机支持提供方。
• W4 Games 商业模式不抽成游戏收入，不影响 Godot 引擎本身的开源属性。
• 社区若能找到更好的主机支持方案，应当积极推动。

对独立游戏开发者，Xmohe 建议：如果主机发行是项目核心战略，应当把 W4 Games 服务费用纳入预算。开源不等于"所有事都免费"，理解这一现实是项目预算规划的基础。