不能通过反射调用受保护构造器破坏单例测试，因其违背全局唯一性契约、导致测试脆弱且脱离真实场景；应专注验证功能正确性、状态一致性及线程安全性，优先采用依赖注入或可重置机制提升可测性。
不能也不应该通过 Class.getDeclaredConstructor() 调用受保护（protected）的单例类构造函数来“破坏”单例进行测试。
为什么这是反模式
单例的核心契约是：**全局唯一实例**。强行绕过构造器访问、反射创建新实例，本质上是在测试“单例是否能被破坏”，而不是在验证业务逻辑。这既违背设计意图，又让测试变得脆弱、与实现细节强耦合。
- 一旦构造器改为
private（更常见且更安全），反射会直接抛IllegalAccessException - 若使用枚举单例或静态内部类等更健壮实现，反射根本无法创建新实例
- 测试结果无法说明系统在真实运行时的行为（因为生产环境不会用反射造第二个实例）
真正该测什么
单例类的测试重点应是：**它提供的功能是否正确，以及其全局状态是否按预期工作**。构造方式是实现细节，不是测试目标。
- 调用单例的公共方法，验证返回值、副作用、异常行为
- 如果单例持有可变状态（如缓存、计数器），可在测试前后检查状态一致性
- 多线程场景下，验证
getInstance()是否线程安全（可用ExecutorService并发调用并断言返回同一对象）
如何写可测的单例（推荐做法）
与其设法“黑盒破坏”单例，不如从设计上提升可测性：
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- 优先用依赖注入：把单例作为依赖传入被测类，测试时可轻松替换为模拟对象（Mockito / Mockk）
-
提供可重置机制（仅限测试）：例如添加包私有
resetForTest()方法，在@BeforeEach中清理状态，而非重建实例 - 将核心逻辑抽离为无状态服务类：单例只负责生命周期管理，业务逻辑放在普通类中——这样可直接单元测试逻辑类，无需碰单例
如果真要验证构造器访问控制（极少数场景）
例如做安全审计或框架兼容性检查，可单独写一个反射探针测试，但不参与业务逻辑测试套件：
Constructor<MySingleton> ctor = MySingleton.class.getDeclaredConstructor(); Assertions.assertTrue(Modifier.isProtected(ctor.getModifiers())); // 注意：这里不调用 ctor.setAccessible(true) 或 newInstance()
仅检查修饰符，不触发实例化 —— 这才是安全、合规的反射用法。
