在单一函数实例化所有类并全局调用的主要弊端有哪些？

• 强耦合导致维护灾难：所有类的创建逻辑都硬编码在main里，任何一个类的构造参数、依赖关系变更，都得修改main函数。比如给类A新增一个依赖类X，不仅要调整A的构造方法，还得去main里添加X的实例化并注入到A中。而且所有依赖这些实例的模块都间接绑定到main，牵一发而动全身，后期维护成本指数级上升。

• 完全丧失灵活性与复用性：如果不同业务场景需要同一类的不同配置实例（比如类B在支付场景需要连接生产数据库，在测试场景需要连接测试库），main里只能写死一种实例逻辑，要么就得在main里塞满各种分支判断，把main搞成臃肿的“大杂烩”。其他模块无法按需创建定制化实例，只能被动接受main提供的固定版本，完全适配不了复杂场景。

• 单元测试几乎无法开展：单元测试的核心是隔离依赖，但这种做法下，测试任何一个模块都必须先执行整个main函数，初始化所有类的实例——哪怕你只测类C，也得把A到Z全实例化一遍。如果某个类依赖外部资源（比如Redis、第三方API），测试时根本没法替换成模拟对象，只能带着整个真实环境跑，测试速度慢、稳定性差，完全达不到单元测试的目的。

• main函数沦为“上帝函数”：随着类的数量增长，main里的实例化代码会越来越冗长，各种依赖注入、参数配置堆在一起，可读性极差。到后期没人敢修改main，怕一个小改动引发整个系统的连锁故障，成为项目的“烫手山芋”。

• 依赖关系完全不透明：调用实例的模块只知道从main拿对象，但完全不清楚这个对象依赖了哪些其他类。比如类D的实例依赖类E和F，但调用D的模块根本看不到这些依赖，排查问题时得一层层扒代码，定位问题的效率极低。

内容的提问来源于stack exchange，提问作者bansal