System类采用私有构造器和final修饰，旨在禁止实例化和继承，确保其作为无状态系统工具类的语义一致性，强制通过静态方法调用，杜绝误用并保持与Objects等工具类的设计统一性。

因为System类的设计定位是系统级工具类，不是用来创建对象的。

它本质是静态能力集合

System类封装的是JVM运行时环境相关的功能：标准输入输出（in、out、err）、系统属性获取（getProperty）、时间戳（currentTimeMillis）、数组复制（arraycopy）、退出虚拟机（exit）等。这些能力天然无状态、无需实例化——调用直接走类名，比如 System.out.println() 或 System.currentTimeMillis()。

如果允许 new System()，反而会引发歧义：这个对象该持有哪份输入流？代表哪个JVM实例？多个System对象之间如何同步标准输出？设计上根本不需要这种“多实例”语义。

防止误用和语义污染

• Java默认为无显式构造器的类生成public无参构造器——不加限制，开发者真可能写出 new System()，编译通过但毫无意义，徒增垃圾对象和理解成本
• 私有构造器让 new System() 在编译期就报错，强制所有人走静态入口，从源头切断误用路径
• 看到 private 构造器，团队成员立刻明白：“这是工具类，查静态方法，别new”——这是写在语法里的契约，比注释更可靠

配合final确保设计不可绕过

System类同时被声明为 final：

• 禁止继承，避免子类偷偷引入状态或覆盖行为，破坏系统一致性
• 和私有构造器形成双重保险：既不能 new，也不能 extend，彻底锁死扩展方式
• 这和 JDK 中的 Objects、Collections、Arrays 等工具类保持完全一致，是经过大规模工程验证的实践标准

不是“完全防不住”，而是守住主防线

反射确实能绕过 private 构造器（setAccessible(true)），但这属于非常规手段，且违背设计意图：

• 大厂规范、代码扫描工具、CI检查都会把反射创建System实例视为违规操作
• 私有构造器的目标不是对抗黑客级攻击，而是杜绝日常开发中的随意 new 和继承滥用
• 就像门锁不防电锯，但足够防钥匙没带的同事——它守住的是绝大多数场景下的正确性