使用此类静态HashMap存储全局实例是否属于不良实践？
这种实现暂时能满足基本需求，但存在不少容易被忽略的隐患，并非长期可行的方案，具体问题如下：
隐性依赖难追踪：你认为没有保存静态状态，但
_globals这个静态容器本身就会让所有依赖它的类（比如TextFieldController）产生隐性依赖。阅读TextFieldController的代码时，完全看不到它需要StateManager等实例，排查问题或修改逻辑时，你得全局搜索所有操作_globals的代码，才能理清依赖关系，大幅增加维护成本。线程安全风险：
HashMap不是线程安全类，如果应用涉及多线程操作（比如UI线程与后台线程同时访问_globals），很可能出现并发修改异常、数据不一致等问题。哪怕只在初始化时写入，后续仅读取，也无法保证读取操作的内存可见性，极端情况下可能拿到未初始化的实例。单元测试难以隔离：测试依赖
_globals的类时，无法轻松替换依赖的模拟实例。你必须在测试前手动往静态容器中注入模拟对象，测试后还要清理，否则会污染其他测试用例，导致测试代码臃肿且不稳定。生命周期不匹配：
MainClass初始化时存入的实例，生命周期本应和MainClass绑定，但静态容器_globals的生命周期是整个应用进程。如果MainClass被销毁重建，旧实例仍会留在内存中引发泄漏，新实例覆盖后还可能出现新旧实例混用的诡异bug。扩展性受限：如果后续需要同一个类的多个实例（比如不同模块用不同的
StateManager），以Class作为key的存储方式直接失效，你不得不重构整个全局容器的逻辑。
更合理的替代思路
使用显式的依赖注入（DI），哪怕不用成熟的DI框架，也可以手动实现一个简单的实例容器：
- 用非静态的容器类管理这些全局实例
- 需要依赖的类通过构造器或方法参数接收实例，而非直接从静态容器获取
- 由容器统一负责实例的创建和分发
这种方式既能避免层层传递的麻烦，又能保留依赖的可追踪性、可测试性，同时解决静态容器带来的各种问题。
内容的提问来源于stack exchange，提问作者gabrielsalvador
