在 services.yaml 中用接口全名作服务 ID 并映射到带 @ 前缀的已注册实现类，可实现自动注入；接口绑定仅路由不创建实例，实现类须先被容器加载且无未解析依赖；多实现时需显式 bind 或用更具体接口避免歧义。
直接在 services.yaml 里用接口全名做服务 ID，映射到带 @ 前缀的具体实现类，就能让容器自动注入——前提是那个实现类本身已被注册为服务。
接口绑定必须写在 services.yaml 的 services: 下级
不是定义新服务，而是建立“要这个接口 → 给那个类”的映射关系。YAML 键必须是接口的完整命名空间，值必须是已存在的服务 ID（带 @）：
Psr\Log\LoggerInterface: '@App\Service\CustomLogger'App\Contracts\PaymentGateway: '@App\Service\StripeGateway'
如果右侧写成 'App\Service\StripeGateway'（没加 @），容器会把它当做一个类名去实例化，而不是去查已注册的服务，大概率报错 Class "App\Service\StripeGateway" not found 或构造失败。
实现类必须先被容器识别，否则绑定无效
接口绑定只是“路由”，不负责创建实例。你的 CustomLogger 类得先能被容器加载：
- 文件路径在自动扫描范围内（如
src/Service/CustomLogger.php） - 命名空间匹配配置中的 resource（如
App\: resource: '../src/'） - 类本身没有构造函数参数无法解析（比如依赖了未绑定的
CacheInterface），或需在 YAML 中补arguments:
验证方式：运行 bin/console debug:container --types，看目标接口是否出现在列表里，并指向你期望的实现类。
多个实现共存时，类型提示必须明确
如果容器里存在多个 LoggerInterface 实现（比如 Monolog 默认实例 + 你的 CustomLogger），仅靠 private LoggerInterface $logger 无法保证注入哪个——容器默认选第一个注册的。
这时要干预绑定优先级：
- 在
services.yaml中显式 bind：bind: LoggerInterface: '@App\Service\CustomLogger' - 或改用更具体的类型提示（如自定义接口
App\Contracts\AuditLoggerInterface），再单独绑定
不要试图在构造函数里用变量名（如 $auditLogger）来区分，容器不看变量名，只看类型。
命令、控制器、事件监听器都走同一套机制
只要它们是容器管理的服务（默认都是），就都能受益于接口绑定。比如命令类写 public function __construct(private PaymentGateway $gateway)，只要 App\Contracts\PaymentGateway 已绑定到 StripeGateway，$gateway 就是后者实例。
容易忽略的一点：事件订阅器（EventSubscriberInterface）不走 service 标签注册，但它的构造函数注入完全依赖这套绑定机制——所以接口绑定必须先生效，订阅器才能拿到想要的实现。
