游戏进入暂停状态，并不意味着场景树里的每一个对象都以同一种方式停止。Godot官方master文档《Pausing games and process mode》先说明两项结果：所有节点的二维、三维物理默认停止，部分节点的处理则依各自Process Mode停止或开始。[1] 物理是否运行与节点是否处理，在这份说明中被分别交代。

每个节点都有Process Mode。默认值Inherit表示沿父节点、祖父节点等向上寻找，使用遇到的第一个非Inherit模式；如果祖先中没有找到这样的模式，才采用SceneTree的暂停状态。[1] 因而，“继承”不是只看直接父节点的名字，而是一个有停止条件的向上查找关系。默认所有节点都继承时，游戏暂停便使节点暂停。

其他模式把两种游戏状态直接写进定义。Pausable只在游戏未暂停时处理；WhenPaused只在暂停时处理；Always不论是否暂停都处理；Disabled完全不处理。[1] 来源同时把继承该模式的子节点纳入相应说明。四个名称不是同一种暂停力度的高低等级，而是处理行为与暂停状态之间的不同条件组合。

这种组合说明了暂停界面为何可以属于另一种处理语境。原文菜单例让根节点在暂停时处理，其继承模式的子孙节点随之进入相同条件。[1] 本文只采用这层父子关系，不转写菜单创建、连接或代码步骤。它说明的不是整个游戏继续推进，而是所述节点在暂停状态下仍可承担界面一类任务。

节点停止处理时，文档明确列出_process、_physics_process、_input和_input_event不再被调用。但信号仍能工作，并触发已连接函数，即使函数脚本附在当前不处理的节点上。[1] 因此，停止这些处理回调，不能继续扩大成对象没有任何函数可能被调用。这一限定来自暂停章节本身，不是以信号的一般定义替代暂停规则。

物理默认停止的条件仍然存在。官方特别提醒，即使某节点在暂停期间继续处理，物理也默认不会为它工作。[1] 所以，Always这个名称不能单独证明节点所有相关系统都继续运行；它只回答Process Mode定义的处理条件。把节点处理与物理服务器的状态混合，会使暂停摘要看起来比原文承诺得更多。

文档还描述动画节点暂停当前动画、音频节点暂停当前音频流、粒子暂停，并在游戏不再暂停时自动继续。[1] 这些是被明确点名的对象和状态关系，不是全部业务逻辑、网络任务或线程都停止的证明。对游戏引擎资料读者，读清父级继承、节点处理和默认物理行为，比用一个总括的“全停”更准确。

本篇实际采用官方godot-docs的master分支RST连续文字，不标为4.5或stable发行版。没有运行游戏、读取示意图或修改任何处理模式；首次发布日期未知。这里解释的是暂停框架中不同对象的行为范围，不给帧率、输入或项目运行效果保证。

资料：[1] https://raw.githubusercontent.com/godotengine/godot-docs/master/tutorials/scripting/pausing_games.rst

信息来源

本文基于上述公开资料整理，未使用来源页面的图片、视频或嵌入媒体。