Node 的 owner 与持久化：场景保存时哪些节点会被写盘

编辑器里手摆的场景保存成 .tscn，但"这棵节点树里的哪些节点会被写进文件"不是理所当然的。如果你在运行时 add_child() 挂过节点，可能会困惑：为什么它们不随场景保存？答案在 Node::data.owner 这个字段上。翻 scene/main/node.cpp 和 scene/resources/packed_scene.cpp，这个字段的职责比名字窄得多。

owner 是什么

Node 内部有一个 owner 指针（scene/main/node.h 的 Data 结构里），指向这棵树里"拥有"它的那个节点，语义是持久化归属：

// scene/main/node.h（Godot 4.2.2，有删减）
class Node {
    struct Data {
        // ...
        Node *owner = nullptr; // 谁负责把我写进场景文件
        // ...
    } data;
};

set_owner() 有一条硬约束：新 owner 必须是自己的祖先（或自己），否则直接报 ERR_FAIL_COND 返回。这条约束不是洁癖——owner 的合法性在 PackedScene::pack() 里被当作递归终止条件使用，如果允许任意节点当 owner，保存时递归就会漏节点或死循环。

注意 owner 不影响任何运行时行为：get_node 查找、组遍历、_process 调度都不看它。只在一个地方起作用——序列化。

pack 的递归规则

PackedScene::pack() 最终走到 SceneState::_bind_nodes（scene/resources/packed_scene.cpp）：从场景根出发做 DFS，递归进某个子节点的条件是

// 只有"归属链"落在本场景内的子节点才继续展开
if (child->data.owner == p_base || child->data.owner == nullptr && ...) {
    // 收编为 NodeData，继续递归其子树
}

简化成一条判定：节点的 owner 等于场景根（或属于本场景的 owner 链）→ 写盘；owner 为 null 或指向场景外 → 不写。所以一份 .tscn 里出现的节点集合，恰好等于"owner 链收敛到该场景根"的那批节点。

实例化时 Godot 会做一步重赋值：PackedScene::instantiate() 造出子树后，把其中 owner 指向"场景内某节点"的子节点，统一改指为实例被挂到的那棵外部树的场景根。这一步是二-7 篇讲过的五步实例化里的收尾工作，做完之后这棵树就和你手写摆出来的没有任何区别，再保存外部场景时整棵都能写盘。

两个容易踩的坑

运行时 add_child() 产生的节点，data.owner 保持 nullptr。这是刻意设计：动态生成的节点（弹出的子弹、生成的敌人）如果跟着场景保存，等于把运行状态固化进资源文件，下次打开编辑器会看到一堆来历不明的节点。想让它们被保存，必须显式 child.owner = get_tree().edited_scene_root 或 set_owner(...)。

反过来的坑也常见：想把子场景实例的某个内部节点挪位置，却发现编辑器里拖不动——因为那个节点的 owner 指向的是子场景的根，不属于当前编辑的场景，保存时根本不会被写。editable_instance（右键实例 → Editable Children）做的事就是临时把当前场景根的写入权扩展到实例内部，等价于批量重指 owner。

owner 和 unique name 的分工

owner 还有一个附带用途：引擎内部用它圈定 unique name 的查找域（%Node 语法只能找到 owner 链内的唯一名节点），对应 Node::get_node("%Foo") 在 owned_unique_nodes 哈希表里查。但这只是实现上的复用——owner 的设计本意始终是序列化归属，别拿它当"逻辑上的父节点"用，逻辑父子关系由 data.parent/data.children 表达，两者经常被搞混。

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