java封装不直接避免全局变量滥用，而是通过private static+受控访问、职责明确的对象替代、不可变配置注入及无状态工具类等机制，从设计上阻断全局可写。
Java 中封装本身不直接“避免”全局变量滥用，而是提供一套机制，让开发者自然远离 public static 变量这类伪全局变量。关键不是禁止，而是用封装原则重新组织状态归属——把本该属于某个上下文的数据，还给它该在的地方。
用 private static + 明确访问方法替代 public static
真正需要跨实例共享的状态（如配置、计数器、缓存），应声明为 private static，再配以受控的公共访问方式：
- 只读配置：用
private static final String API_VERSION = "v2";，配合public static String getApiVersion()—— 不暴露引用，也不允许修改 - 可变状态（如重试次数）：用
private static int maxRetryCount = 3;，写一个带校验的public static void setMaxRetryCount(int count)，拒绝负数或过大值 - 缓存集合：声明
private static final Map<string user> USER_CACHE = new ConcurrentHashMap();</string>，不提供直接访问 map 的 getter，只暴露getUserById(String id)和putUser(User u)等语义化方法
把“全局逻辑”下沉为有边界的协作对象
很多被当成全局变量使用的，其实是职责模糊的服务或工具。封装主张把它变成明确生命周期和依赖关系的对象：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 日志记录器不用
public static Logger LOGGER，而用依赖注入方式传入 Logger 实例，或通过 LoggerFactory 获取，确保作用域清晰 - 时间获取不写
public static LocalDateTime NOW = LocalDateTime.now();，而是封装成ClockService接口，测试时可轻松替换为固定时间实现 - HTTP 客户端不裸露 static OkHttpClient 实例，而是封装为
ApiClient类，内部持单例 client，对外提供postOrder(Order order)这类业务方法
用构造注入 + 不可变对象替代运行时共享变量
所谓“全局开关”“环境标识”等，往往只是启动期确定的一次性值。与其放在 public static 字段里任人读写，不如：
- 定义
AppConfig类，字段全final，通过构造器或 Builder 初始化 - 在应用入口（如 Spring Boot 的 @Configuration 或主类）中创建唯一实例，再以依赖方式传递给需要它的组件
- 避免出现
Config.getInstance().setDebugMode(true)这类破坏不可变性的调用
警惕“静态工具类”变相成为全局变量容器
像 StringUtils、DateUtils 这类工具类本身合理，但一旦开始往里塞状态，就滑向全局变量陷阱：
- ❌ 错误：在
StringUtils里加public static boolean isLegacyMode = false; - ✅ 正确：把模式判断逻辑移到具体业务类中，或作为参数传入工具方法，如
formatName(name, legacyMode) - 工具方法必须是无状态的：不读写任何 static 字段，不持有上下文，输入决定输出
封装不是靠删掉 public static 来规避问题，而是通过明确责任归属、限制访问路径、强化初始化约束，让“全局可写”这件事在设计上就走不通。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
