启动时必须确保配置对象存在，因此在游戏主类初始化时主动创建默认Config实例，其字段均设合理初值，并通过ConfigFactory统一管理加载与兜底逻辑。
启动时确保至少有一条配置，关键在于把配置当作对象来管理，而不是硬编码或依赖外部文件是否存在。最直接的方式是：在游戏主类初始化时，主动创建一个默认配置实体。
配置类必须支持默认构造
定义一个 Config 类，它的构造函数不强制传参，而是为所有字段提供合理默认值：
- 最小值默认为 1
- 最大值默认为 100
- 最大尝试次数默认为 5
- 难度标识（如 "easy"）可设为空字符串或固定值
这样即使没有加载任何外部配置，new Config() 就能立刻生成一条合法、可用的配置实例。
游戏入口处主动初始化配置对象
在游戏启动逻辑（比如 main 方法或 Game 类的构造函数）中，不等待“读取配置成功”才继续，而是先创建默认配置，再尝试覆盖：
- Config config = new Config(); // 确保总有实例
- loadFromJson(config); // 尝试从文件/资源加载，只更新字段，不替换对象
- validate(config); // 校验范围合理性，异常时仍保留默认值
避免空引用和配置缺失陷阱
不要用 Config config = loadFromFile() 这种可能返回 null 的方式。面向对象的核心是“实体存在”，所以：
- 所有配置访问都基于非 null 对象引用
- 字段用基本类型（int）或不可变包装（Integer、String）并设初值
- getter 方法不抛异常、不返回 null，例如 getMin() 总返回一个 int
用工厂方法封装配置构建逻辑
把“获取可用配置”的逻辑集中到一个 ConfigFactory 中：
- public static Config getDefault() { return new Config(); }
- public static Config fromFile(String path) { ... fallback to default on fail; }
- Game 启动时调用 ConfigFactory.fromFile("config.json")，内部保证返回非 null 实例
这样既保持灵活性，又杜绝了启动时无配置的风险。
