在Node.js与TypeScript中以全局上下文作为DI容器的可行性探讨

可行性判断 #

这个方案完全可行，能快速实现依赖共享，不用额外引入DI容器或写复杂的自定义逻辑，适合小型项目或者快速做原型的场景，代码简单直接，能满足基本的依赖注入需求。

潜在弊端 #

• 类型安全没保障：如果用TypeScript，global.deps没有明确的类型约束（除非手动声明），很容易出现属性拼写错、类型不匹配的问题，而且要到运行时才会暴露错误，调试起来麻烦。
• 依赖关系看不明白：路由模块直接拿全局变量用，从代码里没法直观看出它依赖哪些服务，维护的时候得全局找依赖来源，项目一大，代码的可读性和可维护性会掉得很厉害。
• 测试不好做：单元测试的时候没法轻松替换依赖（比如把真实的AuthService换成Mock对象），因为全局变量是共享的，改了会影响其他测试用例，还得额外处理全局状态的重置，增加测试的复杂度。
• 容易搞乱全局命名空间：global是Node.js的全局命名空间，加个deps可能和其他第三方库或者自定义代码的全局变量重名，引发很难排查的冲突问题。
• 扩展起来费劲：项目规模变大、依赖变多的时候，全局deps会变得臃肿，没法管理依赖的生命周期（比如单例、按需实例化），也做不了依赖懒加载或者请求级别的范围注入。
• 不符合模块化原则：每个模块应该通过显式声明来拿需要的资源，而不是偷偷依赖全局变量，这种写法违背了模块化的单一职责和依赖倒置原则，代码耦合度很高。

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