单例组件的构造器必须私有化，以从编译期杜绝非法实例化，确保唯一实例、封装闭环、设计契约明确及未来扩展可控。
是的，所有单例组件的构造器必须私有化——这不是形式主义，而是守住单例语义不可妥协的底线。
从编译期掐断非法实例化的可能
Java 默认为无显式构造器的类生成 public 无参构造器。一旦开放，任何代码都能写 new Singleton()，哪怕只是临时调试、误操作或新人不熟悉约定，都会绕过 getInstance() 创建新实例。私有构造器让这种写法直接编译失败，强制所有创建路径收束到统一入口。
- public 构造器 → 编译通过 → 运行时可能产生多个实例 → 单例失效
- private 构造器 → 编译报错 → 开发者必须查 getInstance() → 行为受控
保障 instance 字段的封装闭环
单例的核心是那个 private static Singleton instance。它的初始化（new Singleton()）必须且只能发生在类内部。私有构造器正是这个“内部创建”合法性的前提：它确保 new 操作不会泄露到外部，也不会被子类继承调用，从而和 static 字段、getInstance() 方法共同构成“私有创建 + 全局唯一引用”的完整封装链。
- static 保证存储位置唯一
- private 修饰防止字段被篡改或提前访问
- private 构造器锁死 new 的调用边界
向协作者传递明确的设计契约
看到 private 构造器，开发者立刻能识别：“这是单例”“不该 new”“要走工厂方法”。它比注释更刚性，比文档更贴近代码，是一种写在语法层的自解释契约。JDK 中的 Objects、Collections，Spring 和 Guava 里的同类设计，全部遵循这一实践——统一风格大幅降低团队理解成本和协作熵值。
- 新人不会因“能 new”而困惑“该不该 new”
- Code Review 不再需要反复拦截 new 工具类/单例的低级错误
- 设计意图无需口头解释，代码本身就在说话
为未来演进预留安全接口空间
单例不是一成不变的。未来可能需要加懒加载、参数校验、日志埋点、依赖注入，甚至测试替身。这些增强逻辑都必须自然收口到 getInstance() 中。如果构造器开放，调用方随时可能绕过它直接 new，导致行为分裂、状态不一致。私有构造器天然倒逼所有创建路径收敛，让扩展始终可控、可测、可维护。
- 所有初始化逻辑集中一处，便于统一管控
- 避免反射或继承带来的滥用风险（配合 readResolve() 可补全反序列化防线）
- Android 混淆时需加保留规则：-keepclassmembers class * { private void
(); } ，否则 R8 可能误删
