Godot 数据资源

要解决的问题

在 Godot 项目里，最常见也最隐蔽的一类技术债是把数据写死在代码里。例如一个剑士的攻击力写在 _ready() 里，一个对话脚本里塞满了条件分支，或者敌人数值散落在各个脚本的局部常量中。每次数值调整都要改代码、走完整编译流程，策划和程序之间的协作边界也因此模糊。

更棘手的问题是运行时数据无法持久化。你在编辑器里手动配好的物品表，一打包发布就消失殆尽。想让数据资产像代码一样进入版本控制、可被 diff、可被多人协作编辑，靠散装常量是做不到的。

这个技能如何工作

这个技能的核心思路是：把游戏数据建模为 Godot 4.3+ 中的 Resource 子类，而不是硬编码值。

• 用 class_name 和 @export 定义数据类：一旦声明了 class_name，这个类就会出现在编辑器的 "New Resource" 对话框里，同时能作为 @export 的类型被其他节点直接引用，在 Inspector 中可视化编辑。
• 实例化为 .tres 或 .res 文件：.tres 是纯文本格式，天然适合 diff 和版本控制；.res 是二进制格式，体积更小、加载更快。创建后直接在 Inspector 里填字段，不需要写一行代码。
• 通过 @export 引用到节点：比如 @export var data: ItemResource，或者 @export var loot: Array[ItemResource]。节点就变成了资源的消费者，而非数据的持有者。
• 运行时加载：常量路径用 preload（编译期加载），变量路径用 load 或 ResourceLoader.load。大资源可以用 load_threaded_request 做后台加载。
• 保存与修改：运行时生成或编辑的资源通过 ResourceSaver.save 落盘。

适用边界与注意点

• 资源是引用共享的：同一个 .tres 被多个节点使用时，它们持有的是同一个对象。运行时修改它会影响所有节点，并且可能覆盖编辑器里的原始文件。需要隔离状态时，先 duplicate(true)。
• class_name 是必须的：缺少它，类不会出现在编辑器的新建资源对话框中，也无法作为 @export 类型使用。
• res:// 是只读的：打包后的游戏无法写入 res://，运行时数据要写到 user:// 下。编辑器里可以保存到 res:// 仅限开发时。
• 不要把节点直接存进 Resource：Resource 序列化的是数据，不是场景节点。需要引用场景时应该用 PackedScene。
• 避免循环引用：A 持有 B、B 又持有 A 的结构在保存/加载时容易出错，应该用 ID 查找来解耦。
• 不要在 .tres 里放秘密信息：导出包中它是明文可见的。
• 区分场景结构与数据资源：本技能只处理数据层面的 Resource，节点/场景的实例化与组织请用 godot-nodes-scenes；运行时存档与读档用 save-systems。