感觉GodotC# 版本用Resource很鸡肋啊。
首先得继承自Resource，然后使用GlobalClass的attribute把类标记一下，但是不支持泛型类，而且还必须要求该文件只能有这一个类。
一般来说resource是适用于数据模型的，类定义的内容应该不多，分散到多个文件可能不太好管理。
然后就是必须得使用Export attribute标记需要在编辑器中显示的属性，但是export却只能用在godot的类型上，并且如果是export的variant类型属性还不能在编辑器编辑，也不能export C井 的集合。都知道用godot的集合的话每次都得向底层进行封送，会占用部分性能，虽然这些性能消耗几乎可以忽略不计，但是我们用C井的时候一般也不会用godot的集合，这就导致我们每次都得从godot集合构造一个C井集合，所以比较麻烦很鸡肋。
我个人配置数据的时候使用的数据容器还是倾向于使用json，当然json序列化和反序列化的API也是使用的Json.NET。
不过内部读取数据的时候一些io操作可能难免需要用到godot的API，因为资源目录的问题，虽然没试过用绝对路径来加载资源目录里（res）配置的游戏数据，但我觉得导出后的包体是将资源目录内的文件都包含进去了的，所以用绝对路径读取位于资源目录的json文件可能会出错
首先得继承自Resource，然后使用GlobalClass的attribute把类标记一下，但是不支持泛型类，而且还必须要求该文件只能有这一个类。
一般来说resource是适用于数据模型的，类定义的内容应该不多，分散到多个文件可能不太好管理。
然后就是必须得使用Export attribute标记需要在编辑器中显示的属性，但是export却只能用在godot的类型上，并且如果是export的variant类型属性还不能在编辑器编辑，也不能export C井 的集合。都知道用godot的集合的话每次都得向底层进行封送，会占用部分性能，虽然这些性能消耗几乎可以忽略不计，但是我们用C井的时候一般也不会用godot的集合，这就导致我们每次都得从godot集合构造一个C井集合，所以比较麻烦很鸡肋。
我个人配置数据的时候使用的数据容器还是倾向于使用json，当然json序列化和反序列化的API也是使用的Json.NET。
不过内部读取数据的时候一些io操作可能难免需要用到godot的API，因为资源目录的问题，虽然没试过用绝对路径来加载资源目录里（res）配置的游戏数据，但我觉得导出后的包体是将资源目录内的文件都包含进去了的，所以用绝对路径读取位于资源目录的json文件可能会出错
实际上我从来没用过Resource系统，和1楼一样使用的是json（因为json作为比较通用的数据格式，反而有各种易于使用的外部编辑器，个人感觉要比export要好编辑多了，尤其是对于大批量的数据）
，例如：
