NodePath 的解析与缓存：get_node 每次调用都重新解析吗

get_node("UI/HUD/Label") 每帧调用一次的代码到处都是，性能讨论里常有人说"get_node 每帧解析字符串很慢"。这句话半对半错：NodePath 的字符串切分确实只发生一次，但逐级查找每次都重新走。翻 core/string/node_path.cpp 和 scene/main/node.cpp，把"解析"和"查找"两段成本分开算，结论会影响你缓存引用的写法。

NodePath：构造期解析的不可变结构

NodePath 不是字符串。构造时就把路径拆好了（core/string/node_path.h，成员示意）：

class NodePath {
    Vector<StringName> path;     // "A/B/C" 拆成三段
    Vector<StringName> subpath;  // "A:B:c" 冒号后的属性子路径
    bool absolute = false;       // 是否 "/" 开头
    // 预解析出的元数据：每一段是普通名、.. 还是 .
    // 以及是否带 unique_name 标志（% 前缀）
};

NodePath("UI/HUD/Label") 构造时走一次拆分循环，按 / 切段、每段 intern 成 StringName（哈希缓存过的名字，比较时比内容比的是哈希值）。之后的 NodePath 对象是纯数据：get_node() 拿到的 NodePath 参数不需要再做任何字符串操作。

这解释了为什么 GDScript 里 $UI/HUD/Label 的编译产物是 get_node(NodePath("UI/HUD/Label"))——NodePath 常量是在脚本的常量区预构造好的，运行时只有整数索引的数组可读。所以"每帧重新解析字符串"不成立，字符串工作在加载脚本时就做完了。

查找：每级一次名字比对

真正的成本在 Node::get_node_or_null 的逐级查找。对每一段名字，Node 要在自己的子节点里找到同名者（node.cpp 的子节点查找逻辑，示意）：

// 逐级在 data.children 里按名字比对（StringName 比较）
for (int i = 0; i < data.children.size(); i++) {
    if (data.children[i]->data.name == p_name) {
        current = data.children[i];
        break;
    }
}

子节点按名字查找，单级成本随兄弟数线性增长（StringName 的比较本身很快——比的是缓存的哈希值，不是逐字符——但数组扫描免不掉）。宽父节点（一个节点挂几十上百个子节点）上的深路径是最坏情况。

把整段路径的成本写出来：路径深度 $d$、最宽一层的兄弟数 $w$，则一次 get_node 最坏约

$$ T_{get\_node} \approx d \cdot O(w) \cdot t_{cmp} + t_{call} $$

$d$ 通常是 2~5、$w$ 通常是个位数，单次就是几十到几百纳秒。这个数字看起来很小，乘上"每帧上千个节点 × 每节点调几次"就值得注意了：它属于白烧，因为结果完全可以钉成引用。

引擎不缓存结果，这是设计

关键事实：get_node 没有结果缓存。第 N 次调用和第一次走完全相同的查找路径。原因不难理解：缓存结果意味着监听整棵子树的名字/结构变化来失效——每个 set_name、每次 add_child、每次 move_child 都要检查"有没有路径缓存指向这里"，而名字索引（children_cache）已经把单级查找压到 $O(1)$，再叠一层结果缓存是把 $O(d)$ 换成 $O(1)$ 却引入失效复杂度，得不偿失。

所以"缓存"这件事被明确推给了使用方，而 Godot 的使用方是脚本。这就是 @onready 的存在意义：

@onready var label = $UI/HUD/Label

展开后等价于在 _ready() 开头执行 label = get_node("UI/HUD/Label")——一次性查找，之后每帧用的是变量里的直接引用，连哈希都不再碰。注意 @onready 没有任何运行时魔法，它就是生成器把赋值挪进了 _ready，和你手写一模一样。

三种"缓存"别搞混

讨论这个话题时有三层东西经常被混为一谈：

NodePath 结构缓存：字符串 → 段的解析，发生在 NodePath 构造时（脚本加载期），运行时零成本。这层引擎帮你做了。
单级名字比较：StringName 按缓存哈希值比较，比逐字符快，但子节点数组扫描仍在。这层引擎部分做了。
完整路径结果缓存："A/B/C" → 节点指针的映射。这层引擎没做，由 @onready 变量在脚本层提供。

所以写代码的决策很简单：路径查一次就够的（初始化、事件响应），直接写 $Path 没问题；在 _process / _physics_process / 高频信号回调里的 get_node，全部换成 @onready 缓存的引用。唯一要小心的是缓存的引用在节点被 queue_free 后会变成悬空指针——GDScript 里 RefCounted 节点引用自动置 null（is_instance_valid 可判），但直接解引用还是会报"已删除的实例"。

绝对路径、相对路径与 ".."

get_node("/root/Level/UI") 是绝对路径，从树的根窗口开始走，.. 相对路径逐级上溯。绝对路径每次都要从根往下 $d$ 级，比相对路径贵；../Sibling 要先爬上父级再查——上溯本身也要逐级的 data.parent 指针跳转，深度大时也不便宜。

性能之外，绝对路径还有个脆弱点：它把"这棵树根部叫什么"编进了代码，autoload 改名、把场景嵌进别的场景时全得改。相对路径和 unique name 才是日常该用的；绝对路径留给确实锚定全局的东西（"/root/Global" 访问 autoload）。

本文代码引自 Godot 4.2.2-stable 的 core/string/node_path.h、scene/main/node.h、scene/main/node.cpp，均有删减。