Godot 技术实践（四）：从可玩到可发布的调试、性能与导出

编辑器里能通关，只说明快乐路径在你的机器上成立。发给别人之后，常见的是输入键位冲突、字体缺字、导出后读不到 res:// 以外的文件、低配机上物理抖动、Web 导出卡在首包。发布前要做的不是再加一个系统，而是把调试手段、性能预算和导出清单补齐。

本文是 Godot 技术实践系列第 4 篇。上一篇：用资源和组合把项目结构撑住

一、先让问题能被看见

Godot 自带的调试开关，比临时 print() 值钱：

• 可见碰撞形状：确认 Hitbox 有没有在动画外残留。
• 可见导航 / 可见路径：AI 走偏时先看网格，再看脚本。
• 远程监视器：运行中改 @export 数值，判断是手感问题还是代码问题。
• 监视器里的 Physics / Objects / Video：帧时间是 CPU、物理还是 GPU。

项目里再留一个只在调试构建生效的覆盖层：

extends CanvasLayer

func _process(_delta: float) -> void:
    visible = OS.is_debug_build()
    if not visible:
        return
    $Label.text = "FPS %d | bodies %d" % [
        Engine.get_frames_per_second(),
        get_tree().get_nodes_in_group("actors").size()
    ]

正式导出不会带上这层信息。不要用 if true: 或注释掉的 print 当调试工具，那会在发布分支里留下噪音，也不会在出问题时帮你定位。

输入问题也提前暴露：所有玩法键走 InputMap，不要在脚本里写死 KEY_SPACE。导出到手柄、AZERTY 键盘或移动端触控时，重绑定才有入口。项目设置里的死区和轴灵敏度，应该进设置菜单，而不是留在开发者的手柄上。

二、性能：先量，再改最贵的那一段

Godot 4 的 2D 项目，常见瓶颈不在 GDScript 本身，而在这几处：

1. 每帧 instantiate() / queue_free() 短命对象。 子弹和飘字可以先做池，或限制同屏数量。
2. 过大的物理体数量和过密的碰撞层。 检测盒用 Area2D，静态地形尽量合并，不要给每个瓷砖一个 StaticBody2D。
3. 超大图集或没有压缩的 PNG。 导入时选合适的压缩和尺寸限制，2D 像素游戏尤其要避免无意义的 4K 贴图。
4. 在 _process 里做全图搜索。 get_nodes_in_group 可以，但不要每帧对上百个节点算一次最短距离；空间划分或信号通知更稳。
5. 粒子、灯光、阴影同时开满。 先看监视器的 Video 项，再决定关哪一个。

物理步和渲染帧不同步时，角色会抖。2D 平台建议：

• 物理 tick 保持默认或固定 60；
• 用 move_and_slide() 而不是每帧手动改 position；
• 摄像机跟随用物理帧或平滑插值，不要两个都做。

优化原则是改被测量出来的热点。没有监视器数据就加对象池，通常只是把泄漏换成更难查的复用 bug。官方的 性能介绍 按 CPU/GPU/线程拆过一遍，排期时可以直接当检查单。

三、导出：预设比“点一下 Export”重要

每个目标平台单独做导出预设，不要共用一份含糊配置。

桌面（Windows / Linux / macOS）

• 勾选对应架构，避免只导出了你本机那一种。
• 资源导出过滤器确认 res:// 下的 .tscn、.tres、音频、字体都在包内。
• 用 user:// 存档，不要写到 res://。导出后 res:// 是只读包。
• 像素游戏打开纹理过滤为 Nearest，并在窗口设置里处理整数缩放，避免模糊。

Web

• 线程和 SharedArrayBuffer 依赖托管头，本地 file:// 打不开是正常的。
• 首包体积直接决定加载体验，音频和多语言字体往往比脚本更大。
• 输入焦点、全屏、音频解锁都要按浏览器策略处理。

Android / iOS

• 权限、方向、刘海、回退键提前在真机测。
• 触控不要复用键盘动作名就算完，按钮要有独立 UI。

导出后立刻做一份最小验收：新目录解压、无编辑器、无你的用户目录。能进入主菜单、能新建存档、能读到字体和 BGM，才算导出成功。官方 导出说明 对每个平台的额外依赖写得很清楚，正式发包前对照一遍。

四、一份可直接勾的发布清单

1. 主场景、输入映射、显示与音频总线都在项目设置里，而不是某个人的本地覆盖。
2. 存档只走 user://，并验证导出后读写。
3. 缺字、缺音频、缺翻译会有回退，而不是空白或报错退出。
4. 调试绘制、FPS 覆盖层、作弊键只在 OS.is_debug_build() 下存在。
5. 崩溃时至少能在日志里看到最近场景名和版本号。
6. 窗口模式、整数缩放、手柄热插拔在目标平台测过。
7. 导出预设纳入版本库，export_presets.cfg 里不要放密钥；密钥走本机或 CI 密钥库。
8. 用 git 管理 .tscn / .tres 时保持文本格式，避免二进制场景无法 diff。

版本号建议写进 Autoload 或项目设置，在关于页和日志里打印。别人发来“会卡”的视频时，你需要知道那是哪一次导出。

小结

Godot 项目从可玩到可发布，靠的是能看见的调试信息、有预算的性能和可重复的导出预设。场景树、状态机和 Resource 解决的是“怎么把游戏写对”；这一篇解决的是“怎么让别人也玩得到”。四篇连起来，就是一条从心智模型到发包的实践路径：先组合，再循环，再数据边界，最后才是发布清单。

上一篇：Godot 技术实践（三）：用资源和组合把项目结构撑住