封装通过限制访问、明确职责、控制生命周期，使全局静态变量变得不必要；应改用私有静态字段+受控方法、显式context对象、接口抽象及threadlocal等手段替代。
封装本身不是用来“消除”全局静态变量的工具，而是从设计源头让全局静态变量变得不必要——它通过限制访问、明确职责、控制生命周期，把原本散落在各处、随意修改的静态状态，收束成可追踪、可测试、可管理的对象行为。
用私有静态字段 + 受控方法替代 public static 变量
直接暴露 public static String ENV = "dev" 等同于把开关扔在公共走廊里，谁都可拨。正确做法是：
- 声明为
private static final String DEFAULT_ENV = "prod"，初始化即冻结 - 若需运行时变更（如测试切换），提供带校验的静态方法：
public static void setEnv(String env) { if (isValid(env)) envHolder.set(env); } - 返回值也做封装：不返回原始集合，而用
Collections.unmodifiableMap(cache)或List.copyOf(items)
把“全局上下文”转为显式传入的 Context 对象
当多个类都需要访问用户ID、租户标识、请求ID等“看似全局”的数据时，不要用 public static ThreadLocal<string> userId</string>，而应构造一个轻量 Context：
- 定义
class RequestContext { private final String userId; private final String traceId; ... } - 被测方法签名从
process(data)改为process(data, context) - 测试时可自由构造不同 context 实例，状态完全隔离，无需清理
用依赖注入替代静态工具调用
第三方 SDK 的静态方法（如 HttpClient.send()）或自建工具类（如 DateUtils.format()）一旦参与业务逻辑，就会让单元测试无法替换行为。应：
- 封装一层接口，如
interface HttpClient { Response send(Request req); } - 提供默认实现类，内部调用 SDK 静态方法
- 测试时注入 mock 实现，彻底切断对静态状态的依赖
线程级状态优先选 ThreadLocal，而非 static
仅当确实需要“每个线程一份独立副本”时（如事务上下文、认证信息），ThreadLocal 比 static 更安全：
- 声明为
private static final ThreadLocal<context> CURRENT = ThreadLocal.withInitial(Context::new)</context> - 测试中用
CURRENT.set(testContext)注入可控值 - 务必在
@AfterEach中调用CURRENT.remove()，防止测试间残留和内存泄漏
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
