个人觉得性价比不高，反正游戏的模块绝大部分是单例，直接用就行了。
依赖注入是为了简化全解耦MVC的，如果你游戏是重度MVC的话可以考虑。
另外如果你是个热血小伙很多时间的话，自己实现出来也是可以，反正也就注册、装饰器、arguments判断、传值那套而已。
我觉得依赖注入跟mvc没什么关系,有解耦需求的地方都可以用,而且正是因为没有依赖注入,所以很多模块是用单例的.
实现的话, 理论上不复杂, 而且很多可以参考的, 主要是组件的构造是在引擎内部处理的, 自己要实现得优雅,就得改引擎了,augular那样的估计还得编译器生成额外的代码
无聊，单例和依赖注入有区别吗，不就是实例是个静态变量和统一存在一个地方的区别吗，你也可以搞一个InstanceManager来存起来啊，本质上没有解决任何问题。
这玩意只有对MVC来说是有意义的，把原先对模块的获取简化了。
我一直都说，别滥用设计模式，用设计模式的第一前提就是解决问题，先有问题，再有设计模式。否则就是闲着没事做复杂化。
依赖注入不一定是单例,可以由父节点注入,也不一定全局的,可以有作用域, 参考.net和flutter的provider
依赖注入是用来解决组件依赖性问题,何谓滥用,组件依赖一堆全局变量就不叫滥用了?
你那是用web端和后端的设计思维在考虑游戏设计，实际风马牛不相及，知道游戏的依赖注入鼻祖是什么吗，一个flashAS3的框架，叫robotlegs，设计之初就写明了是为了简化prueMVC框架而设计的，本质就是为了更舒服地写MVC。
要搞什么作用域这些，和是不是依赖注入一点关系都没有，我不是叫你搞一大堆全局变量，我是说依赖注入在模块化上和全局变量没有区别，写一大堆代码没有带来什么好处。要搞作用域，要搞从属关系，这些本来就是游戏里要设计的部分，跟用什么写法一点关系么有，而在这个前提下，依赖注入要增加一大堆设计，所以我说性价比不高，写一大堆，没带来什么好处，没解决任何问题，除了写法“爽？”
另外讲一个依赖注入的大问题，这个设计模式就决定了模块的初始化顺序不受控，而游戏往往是对初始化顺序有要求的应用。
我从robotlegs，angular到vue，到NestJS，不要觉得我是看不起依赖注入，就是用得太多才知道好坏在哪里。
没遇到过你说的初始化顺序问题, 引入这样的框架是为了解决依赖关系的问题,提高组件的可重用性,并不是你说的没解决任何问题,比如给一个人物加血条显示, 是人物依赖血条, 还是血条依赖人物,按你说的话依赖注入就没什么意义了,为何.net把依赖注入加入标准库,建个命令行程序都用依赖注入,没带来任何好处难道是为了写着爽?
为什么总觉得.net这样设计就是一定有意义，想想为什么.net不是后端开发主流架构
你对比一下java
做项目只看星，一看就是个人爱好，不是公司项目，现在除了国企那些屎山项目谁用 .net
不要老待在井底
哈哈哈，可以可以，这种老掉牙的东西可以沉迷半天，符合人设