何时以及为何需要使用注解绑定（Annotation Binding）？

1. 为什么需要区分多个同类型的实例？ #

大量场景下，多个实例属于完全相同的类，只有配置参数不同，根本不存在不同的实现类，你没法通过类型来区分：

• 比如你举的HttpClient例子，两个实例都是同一个HttpClient类的对象，只是初始化传入的目标服务地址不同，一个用来调用Foo服务，一个用来调用Bar服务。你总不能为每一个要调用的下游服务都单独写一个空的HttpClient子类做标识吧？如果你的服务要对接10个下游HTTP接口，就要写10个没用的空子类，完全是冗余代码，维护成本极高。
• 再举个更常见的例子：你需要注入两个String类型的配置，一个是数据库连接地址，一个是第三方服务密钥，总不可能为了这两个值专门写两个String的子类吧？
  这种同类型、不同配置的实例是非常普遍的需求，绑定注解是成本最低的区分方案。

2. 为什么不直接注入具体实现类，而要用接口+绑定注解区分？ #

这是为了遵循依赖倒置原则，实现上层逻辑和底层实现的解耦：

• 上层业务代码只需要依赖通用接口，不需要关心具体实现类的细节。比如你有个支付接口PayHandler，有支付宝AliPayHandler、微信支付WechatPayHandler两个实现。上层业务只需要知道「我要的是支付宝类型的支付能力」，根本不需要知道具体实现类是AliPayHandler还是后续升级的AliPayV2Handler。
• 如果你直接注入AliPayHandler和WechatPayHandler的实例，后续你要把支付宝的实现替换成新的AliPayV2Handler，所有注入了AliPayHandler的代码都要挨个修改，风险高、工作量大。但用绑定注解的话，你只需要修改模块里@Provides @AliPay方法的返回实现，上层注入的地方完全不需要动，对业务代码无侵入。
• 另外多环境切换的场景下也更灵活：比如测试环境你可以给@AliPay限定的实例返回一个Mock实现，生产环境返回真实实现，上层代码不需要做任何修改。

当然如果你的两个实现类的能力根本不通用，只是碰巧实现了同一个空接口，上层逻辑也需要区分二者的能力差异来做不同处理，那确实不需要用绑定注解，直接注入具体类型即可。绑定注解的核心适用场景始终是「上层只需要依赖通用能力，只需要区分同类型实例的不同用途」的情况。

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