类变量与模块化需协同设计：static解决类内状态共享，module-info.java控制跨模块可见性；未导出的包中public static变量仍不可访问，必须exports包并配合requires依赖声明。
类变量声明和程序模块化设计看似属于不同层级的概念，但它们在实际开发中紧密协同：类变量解决的是类内部状态共享问题，模块化则解决的是系统级组件边界与依赖管理问题。真正落地时，二者需统一考虑——比如一个被多个模块共用的计数器类，既要靠 static 保证状态一致，又要靠 module-info.java 控制谁可以访问它。
类变量声明：明确用途与访问边界
类变量（即静态变量）用 static 修饰，属于类本身而非实例，所有对象共享同一份内存。但它不是“天然可跨模块使用”的——即使声明为 public static，若所在包未被导出，其他模块仍无法编译通过。
- 声明时优先考虑是否真需跨实例共享：如连接池大小、全局配置缓存、服务启动时间戳等
- 避免滥用
public static暴露可变状态，尤其在模块化项目中——应封装为不可变或提供受控访问方法 - 初始化时机在类加载阶段，早于任何对象创建；因此不能依赖尚未初始化的实例成员
- 访问推荐用
ClassName.variableName形式，既清晰又避免误用 this 引用
模块化设计：用 module-info.java 管理类变量的可见性
模块化不改变类变量本身的语义，但决定了它能否被其他模块“看见”和“用到”。关键在于 exports 和 requires 的配合。
- 若类变量定义在
com.example.config.AppConfig中，且希望被其他模块读取，则必须在module-info.java中写exports com.example.config; - 消费方模块要引用该变量，除了导入包，还必须声明
requires your.module.name;，否则编译报错 “package is not visible” - 仅导出包还不够：如果变量是
private static final String VERSION = "1.2";，外部仍不可访问——需配合public或提供public static访问方法 - 反射访问（如测试框架读取私有静态字段）需额外加
opens com.example.config;，exports对反射无效
实战组合：一个可配置的限流计数器模块
设想一个限流模块，内部用 static AtomicInteger counter 统计请求次数，对外只暴露 getCount() 和 reset() 方法。
- 把计数逻辑封装在
com.example.rate.Limiter类中，类变量声明为private static final AtomicInteger total = new AtomicInteger(); - 在
module-info.java中导出 API 包：exports com.example.rate.api;，而实现包com.example.rate不导出 - API 接口定义
RateCounter，含public static RateCounter getInstance()工厂方法——这样既隐藏了静态变量，又控制了访问入口 - 其他模块只需
requires com.example.rate;并导入com.example.rate.api.*即可安全使用，无法直接操作底层计数器
常见陷阱与规避方式
很多模块化项目失败，并非因为语法写错，而是忽略了类变量与模块边界的耦合关系。
-
路径错误：module-info.java 放在
src/main/java/com/example/下 → 编译器找不到模块 → 必须置于src/main/java/根目录 -
版本错配：Maven 中未设置 Java 11+ 编译版本 → 模块语法被忽略 → 在
pom.xml的maven-compiler-plugin中指定<release>17</release> -
导出过度：exports 整个包却包含大量内部工具类 → 建议按功能拆分包，只导出带
api或spi后缀的稳定接口包 - 静态状态污染：多个模块加载同一 JAR 的不同版本 → 自动模块可能引发重复类加载 → 应避免在模块间共享可变静态状态，改用服务发现或注入机制
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
