java类变量（static字段）可作为轻量级配置枢纽，适用于中小型项目；应优先使用public static final声明不可变配置，动态配置需同步机制，启动时注入并配合静态方法封装访问逻辑，注意线程安全、测试重置与内存泄漏风险。
Java 类变量（static 修饰的字段）在轻量级应用配置管理中，常被用作集中式、跨类共享的配置枢纽。它不依赖 Spring 等框架，适合中小型项目或启动阶段快速注入配置，但需注意初始化时机和线程安全。
集中声明公共配置项
新建一个 Config 类，统一定义 public static final 常量，避免硬编码和重复定义：
-
API 地址、超时时间、开关标识 等稳定参数，适合声明为
public static final String API_URL = "https://api.example.com"; - 类型推荐使用
final保证不可变性；若需运行时动态修改（如灰度开关），可去掉final，但必须搭配同步机制 - 所有业务类通过
Config.API_URL直接引用，解耦配置来源，便于后期替换为外部配置中心
启动时动态加载配置值
类变量本身支持运行期赋值，可在应用初始化阶段从外部源读取并注入：
- 主类或
static初始化块中调用loadFromProperties()或loadFromEnv()方法 - 例如：
Config.TIMEOUT_MS = Integer.parseInt(System.getProperty("app.timeout", "5000")); - 确保在任何业务代码访问前完成赋值，否则可能读到默认值（如
0、null或false）
配合静态方法提供配置访问封装
仅暴露字段不够安全，建议用 static 方法 封装逻辑，增强可控性：
- 添加校验：如
public static int getTimeout() { return Math.max(1000, TIMEOUT_MS); } - 延迟加载：首次调用时才解析配置文件，避免类加载时阻塞
- 返回不可变视图：对集合类配置（如
static List<string> ALLOWED_HOSTS</string>），用Collections.unmodifiableList()包装
规避常见风险点
静态配置看似简单，但容易埋下隐患：
- 多线程并发修改非
final配置字段时，必须加锁或改用AtomicReference - 测试中静态状态会跨用例残留，单元测试需在
@BeforeEach中重置关键字段（如Config.IS_DEBUG = false） - JVM 生命周期内长期驻留，大对象（如缓存 Map）未及时清理可能引发内存泄漏
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
