子类继承全局配置基类的核心是抽取通用配置为可继承、可覆盖、可扩展的protected final属性，通过带参构造强制初始化，子类按模块或环境定制扩展，统一用父类类型引用实现多态管理，避免滥用继承与配置污染。
子类继承全局配置基类，核心在于把通用配置项抽取为父类的可继承、可覆盖、可扩展的属性结构，再通过访问控制、构造初始化和类型统一实现集中管理。
配置基类设计：定义可继承的公共字段与初始化契约
全局配置基类应使用 protected 修饰关键属性（如数据库URL、超时时间、环境标识），避免 private 封装导致子类无法访问；同时提供带参构造方法，强制子类在创建时完成基础配置注入。
- 不暴露敏感字段为 public，也不用 private —— 否则子类无法读写或需额外 getter/setter
- 所有配置字段建议用 final + protected 声明（如
protected final String env），确保初始化后不可变但子类可读 - 构造方法中调用
super(configMap)或super(env, timeout)，让子类明确传递必要参数
子类继承与差异化配置：按模块/环境定制化扩展
不同业务模块（如订单服务、用户服务）或不同部署环境（dev/test/prod）可分别定义子类，复用父类配置骨架，只重写或新增自身特有属性。
- 子类可通过重写父类方法（如
getRetryPolicy()）动态调整策略，而非硬编码字段 - 允许子类添加专属配置字段（如
private int maxOrderBatchSize），不影响其他模块 - 利用
@Override标注重写逻辑，提升可读性与IDE识别能力
统一管理入口：用父类类型引用所有子类实例
系统启动时加载各模块配置子类，并以父类类型统一注册到配置中心或 Spring 容器中，后续通过多态调用统一接口获取配置值。
立即学习“Java免费学习笔记（深入）”；
- 例如定义
ConfigBase config = new OrderServiceConfig("prod")，调用config.getDbUrl()实际执行子类实现 - 配合工厂模式或 Spring 的
@ConfigurationProperties，自动绑定 yml 中的层级配置到对应子类 - 避免在业务代码中直接 new 具体子类，而是通过 ApplicationContext.getBean(ConfigBase.class) 获取，便于后期替换
注意事项：避免继承滥用与配置污染
继承用于“本质相同、仅细节不同”的配置场景；若差异过大（如支付配置 vs 日志配置），应拆分为独立配置类，改用组合或接口聚合。
- Java 单继承限制下，不要让配置基类承担非配置职责（如连接池管理、加密逻辑）
- 禁止子类修改父类已声明为 final 的配置字段，防止意外覆盖引发环境错乱
- 配置基类本身不应依赖具体框架（如 Spring），保持 POJO 纯度，便于单元测试和跨框架复用
