依赖注入能干嘛？程序员都在用的代码“组装术”

你有没有遇到过这种情况：改一个功能，结果好几个地方都得跟着改，牵一发而动全身？比如做个电商网站，原本支付只支持支付宝，现在要加个微信支付，结果翻代码发现，支付宝的调用到处都是，改起来头大。

依赖注入就是来解决这种麻烦的

它不搞复杂术语，简单说就是：别自己 new 对象，让别人把需要的东西“塞”给你。就像你去咖啡店点单，不用自己种咖啡豆、磨粉、冲泡，服务员直接把做好的拿铁递过来——你要的只是那杯咖啡，过程不关心。

举个例子，有个订单类 OrderService，它需要一个支付功能。传统写法是这样：

class OrderService {
    private PaymentService payment = new AlipayService();

    public void checkout() {
        payment.pay(100);
    }
}

问题来了，要是哪天想换成微信支付，就得进这个类去改代码，风险高还费时间。

用依赖注入换个活法

改成让外部把支付方式传进来：

class OrderService {
    private PaymentService payment;

    // 构造函数注入
    public OrderService(PaymentService payment) {
        this.payment = payment;
    }

    public void checkout() {
        payment.pay(100);
    }
}

这样一来，OrderService 不再关心具体用哪种支付，谁调用它，谁负责把合适的支付方式交给它。想用微信就传 WeChatService，想用银联就传 UnionpayService，代码不动，照样跑。

实际开发中的好处真不少

测试也方便了。比如写单元测试时，不想真去调支付接口，可以用个假的 MockService 代替，快速验证逻辑对不对。没有依赖注入的话，测一次就得联网走真实流程，效率低还容易出错。

团队协作也更顺畅。前端做页面时，后端接口还没好，可以先注入一个模拟数据的服务，页面照常开发，不用干等。等接口一到位，换回真实服务就行，页面代码基本不用动。

现在很多主流框架，像 Spring、.NET Core，都把依赖注入当家常便饭用。不是为了炫技，而是真能减少重复代码、降低模块之间的“黏性”。系统一大，这种设计的优势就越明显。

小到一个工具类，大到整个应用架构，只要存在“某个东西需要用到另一个东西”的情况，依赖注入都能派上用场。它不解决具体业务问题，但能让代码更灵活、更容易维护。