依赖注入真只为代码好看？省服务器钱才是正经事

你优化过代码，但优化过服务器账单吗？

有个程序员发现，依赖注入（Dependency Injection，依赖注入）这门"架构美学"，真正的用武之地其实是让单台服务器扛住更多请求——而这件事，很多开发者根本没想明白。

请求进来时，到底发生了什么？

想象一个典型的Web请求：用户点击按钮，数据包穿过网络，最终变成你代码里的一个对象。在.NET这类框架里，它会被塞进HttpContext（请求上下文）。

但这只是开始。

为了处理这个上下文，你的应用会瞬间"爆"出一堆对象：数据库连接、日志记录器、缓存客户端、配置读取器……它们像链条一样互相勾连，作者叫它"对象集群"（Object Cluster）。

一个请求 = 一个对象集群。这很合理，对吧？

直到并发量上来。

1000个请求同时砸过来，就是1000个对象集群在内存里横冲直撞。CPU忙着创建销毁，RAM被撑到极限。没有管控机制的话，服务器直接窒息。

这就是依赖注入被发明出来的真正场景——不是为了代码好看，是为了让对象"死得其所"，不浪费每一字节内存。

对象的三种"活法"

依赖注入的核心武器，是控制对象的生命周期（Lifetime）。作者把它比作"生死协调员"，有三种模式：

Singleton（单例）：全局只有一个实例，所有请求共享。适合无状态服务，比如配置中心。

Scoped（作用域）：每个请求周期内只有一个实例，请求结束就销毁。数据库上下文通常放这里。

Transient（瞬时）：每次被请求都新建一个实例。轻量、无共享风险，但创建成本最高。

选错模式，就是选错账单。

把该用Singleton的配成Transient，内存爆炸；把该用Transient的配成Singleton，线程安全问题找上门。作者说的"不浪费单字节RAM"，背后是实打实的云服务器费用。

解耦是赠品，省钱才是本体

当然，依赖注入还有另一张面孔：依赖倒置（Dependency Inversion）。模块之间不直接new对象，而是通过接口注入，换来的是随时替换实现而不崩坏整个链条。

但作者把这称为"The Other Side of the Coin"——硬币的另一面。言下之意，这是附赠的，不是主菜。

这个视角挺反直觉。我们学依赖注入时，教科书都在讲"解耦""可测试性""面向接口编程"。但跑到生产环境一看，真正让你半夜被报警吵醒的，往往是内存泄漏和CPU飙高。

作者留了个钩子：解耦的话题"太深，下篇再聊"。这篇只聚焦在资源管理上。

为什么这事值得重新想一遍？

技术圈有个怪现象：越是基础的概念，越容易变成"正确的废话"。

人人都说依赖注入好，但问到"你的Singleton里塞了多少不该共享的状态"，很多人答不上来。云原生时代，服务器成本按秒计费，对象生命周期配置错误，直接翻译成真金白银的浪费。

作者说这是自己第一次写这个话题，欢迎挑刺。这种坦诚挺难得——毕竟依赖注入被写烂了，能挖出"省服务器钱"这个切入点，说明真在生产环境里踩过坑。

下次review代码时，不妨多问自己一句：这个对象的生命周期，是在帮公司省钱，还是在帮云厂商冲业绩？