Godot 如何避免滥用节点 (Node)

一、 节点的代价

虽然在 Godot 中创建一个节点（Node）的开销很低，但这种低开销是有上限的。
一个中型项目可能有成千上万个节点在同时运作。如果这些节点的行为越复杂，每一个节点给项目性能带来的压力就越大。

为什么不能滥用节点？
节点（Node）自带了许多通用功能（如位置变换、父子层级、生命周期回调 _ready / _process 等）。如果你只是为了存储数据或处理纯逻辑，使用节点就像是“开着卡车去买瓶水”——既浪费内存，又占用 CPU 处理时间。

Godot 提供了一些更轻量级的对象作为替代方案。在设计项目架构时，请务必将以下选项作为优先考虑对象。

---

二、 快速决策：我该选什么？

在决定使用哪种对象之前，请参考以下决策流程：

1. 需要画面显示、物理碰撞或场景树层级吗？

   • 👉 是： 使用 Node (节点)。
   • 👉 否： 继续下一步。

2. 需要保存为文件，或需要在编辑器检查器（Inspector）中配置数据吗？

   • 👉 是： 使用 Resource (资源)。(如：装备属性、技能配置)
   • 👉 否： 继续下一步。

3. 需要自动管理内存（不想手动 free）吗？

   • 👉 是： 使用 RefCounted。(如：纯逻辑类、临时数据包)
   • 👉 否： 继续下一步。

4. 是否在构建极其底层的系统，且对性能极其敏感？

   • 👉 是： 使用 Object。(极少情况，通常 RefCounted 已足够)

---

三、 三大轻量级替代方案详解

1. Object (原始对象)

官方定义：
极致轻量的对象。原始的 Object 必须使用手动内存管理。话虽如此，创建自己的自定义数据结构（甚至是节点结构）并不太难，而且比 Node 类更轻量。

• 核心特点： 最轻量、最底层、需手动 free()。
• 官方示例： Tree 控件。
  Tree 是一个 UI 节点，但它内部用来展示行和列的数据并不是子节点，而是 TreeItem 对象。这使得它能轻松处理数千行数据而不卡顿。

• 深度解读：

  • 这是 Godot 对象系统的基石。
  • 风险提示： 必须极其小心。你可以将 Object 存入变量，但如果该对象被其他地方删除了，你的变量引用就会失效（Dangling Pointer），导致程序崩溃。
  • 适用场景： 编写极其底层的 API 或自定义数据结构，且你需要完全掌控内存的分配与释放。

2. RefCounted (引用计数对象)

官方定义：
仅比 Object 稍微复杂一点。它们会追踪自身的引用，只有在没有任何引用指向它们时，才会删除已加载的内存。在大多数需要自定义类数据的场景中，它们都非常有用。

• 核心特点： 自动内存管理（自动挡）、省心、不会内存泄漏。
• 官方示例： FileAccess。
  文件读写对象用完即走，不需要开发者手动调用删除方法。

• 深度解读：

  • 这是非节点逻辑开发的首选。
  • 只要有变量拿着它，它就活着；没变量拿着它，它就自动销毁。
  • 适用场景： 纯逻辑类（如伤害计算器）、临时数据结构、不需要存盘的运行时对象。

3. Resource (资源)

官方定义：
仅比 RefCounted 稍微复杂一点。它们天生具备序列化/反序列化（即保存和加载）其对象属性到 Godot 资源文件（或从中读取）的能力。

• 核心特点： 可存盘（.tres/.res）、可复用、检查器（Inspector）可见。
• 官方示例： 脚本、PackedScene、AudioEffect。

• 深度解读：

  • 继承自 RefCounted，所以也是自动管理内存。
  • 最大的优势： 它像节点一样可以在编辑器里可视化编辑属性，但运行时却比节点轻得多。
  • 数据共享： 多个节点可以引用同一个 Resource（例如 100 个敌人共用一份“攻击力配置”资源），极大地节省内存。
  • 适用场景： 替代“数据节点”。如果你以前习惯创建一堆 Node 只是为了在里面填变量，现在请改用 Resource。

---

四、 总结与形象化比喻

为了方便记忆，我们可以将 Godot 的对象体系比喻为：

最佳实践建议：
不要因为习惯了 Node 就放弃了这些强大的工具。通过将数据移入 Resource，将纯逻辑移入 RefCounted，仅将必须的可视化/物理组件保留为 Node，你的 Godot 项目将拥有更好的结构和更流畅的性能。