GDScript无显式文件链接，如何组织大型可复用库？

针对你移植大型库（原JS/C#版本拆分为50+文件）的需求，除了你提到的两种方案，GDScript还有更优的模块化组织方式，核心是利用preload实现类似JS/C#的文件引用逻辑，同时避免全局作用域污染：

一、基于preload的私有模块引用 #

这是最接近JSimport、C#类引用的方案，完全不需要给内部模块设置class_name，仅在主库脚本中通过preload加载依赖模块，内部模块的作用域被限制在主库内：

1. 目录结构规划：按功能拆分文件到子目录，比如：

   lib/
   ├─ MyLibrary.gd       # 对外暴露的主API入口
   ├─ core/
   │  └─ CoreModule.gd
   └─ utils/
      ├─ UtilA.gd
      └─ UtilB.gd
   

2. 主库脚本实现：在MyLibrary.gd中预加载内部模块，对外仅暴露公共API：

   # MyLibrary.gd
   class_name MyLibrary  # 仅这个类暴露到全局
   
   # 预加载内部模块，仅在当前脚本内可见
   const CoreModule = preload("res://lib/core/CoreModule.gd")
   const UtilA = preload("res://lib/utils/UtilA.gd")
   const UtilB = preload("res://lib/utils/UtilB.gd")
   
   # 公共API，封装内部模块的功能
   func process_data(input):
       var core_result = CoreModule.parse(input)
       return UtilA.format(core_result)
   
   static func get_util_b_helper():
       return UtilB.new()
   

3. 内部模块实现：子模块不需要设置class_name，直接定义类或函数：

   # res://lib/utils/UtilA.gd
   class UtilA:
       static func format(data):
           return JSON.stringify(data)
   

这种方式完全避免了全局作用域污染，内部模块仅在主库中可访问，符合封装原则，和你熟悉的JS/C#模块化逻辑一致。

二、内部类嵌套+多文件拆分 #

如果部分模块和主库关联紧密，可以将核心逻辑放在主库脚本，把辅助类通过preload导入后作为内部类使用，或者直接在主库中嵌套定义类，同时把复杂的辅助逻辑拆分到单独文件：

# MyLibrary.gd
class_name MyLibrary

# 将外部文件的类导入为内部类
const _UtilA = preload("res://lib/utils/UtilA.gd").UtilA

# 主库内部嵌套类
class CoreProcessor:
    func parse(input):
        return _UtilA.preprocess(input)

三、单例模式配合资源脚本 #

如果你的库是全局工具类或服务型库，可以将主库设为自动加载的单例，内部模块作为普通脚本（无class_name）通过preload加载，对外仅通过单例暴露API：

1. 在Godot项目设置的“自动加载”中添加MyLibrary.gd，使其成为全局单例。
2. 主库脚本内预加载所有内部模块，封装公共方法，用户仅通过MyLibrary.instance或直接调用静态方法访问功能。

方案对比 #

• 对比“单文件”方案：实现了文件拆分，每个功能模块独立维护，代码结构清晰，适合50+文件的大型库。
• 对比“带前缀class_name”方案：彻底避免了全局作用域污染，内部模块完全封装，用户无法直接访问，符合公共API的设计原则。

综上，基于preload的模块化方案是你当前需求的最优选择，既满足了大型库的文件拆分需求，又保持了封装性，和你熟悉的JS/C#开发逻辑对齐。

内容的提问来源于stack exchange，提问作者jamesplease