Symfony服务别名不参与autowire候选，仅影响接口类型获取（如get()），需禁用自动装配或用bind显式指定；别名须定义在services根层级，后定义覆盖先定义，调试应以debug:container --types输出为准。
服务别名导致 autowire 找不到具体实现类
当你在 Symfony 中为一个接口定义了多个实现类，并用 alias 指向其中一个，但又没关掉自动装配的“宽松模式”，容器会直接返回别名指向的服务——哪怕你本意是注入某个具体实现。这不是 bug，是设计行为。
常见错误现象：Cannot autowire service "App\Service\PaymentProcessor": multiple services exist for the same interface. 或者更隐蔽地：注入了 A 实现，但实际需要的是 B 实现，运行时才出逻辑错。
- 必须显式禁用该接口的自动装配，或在需要的地方用
bind强制指定 - 别名本身不参与
autowire: true的候选池；它只影响通过接口类型直接获取服务的行为（比如$container->get(PaymentProcessorInterface::class)） - 若依赖注入链中某处用了
new或工厂方法绕过容器，别名完全无效
services.yaml 里 alias 写法和优先级陷阱
Symfony 的别名不是“覆盖”，而是“映射”。写错位置或重复定义，容易让别名被忽略，或者生效顺序不符合预期。
使用场景：你想把 App\Service\LegacyMailer 当作 MailerInterface 的默认实现，但项目里还存在 App\Service\SwiftMailerAdapter 和 App\Service\SymfonyMailerAdapter。
- 别名必须定义在
services:根层级下，不能嵌套在某个服务的bind或arguments里 - 同名别名后定义的会覆盖先定义的，但若两个文件都定义了同一别名（比如
packages/下多个 YAML），加载顺序取决于文件名排序，不可靠 - 别名目标必须是已声明的服务 ID，不能是类名（除非该类已被自动注册且 ID 未被修改）
正确写法示例：
services: MailerInterface: '@App\Service\LegacyMailer'
调试别名是否生效：用 debug:container 看真实绑定
光看 services.yaml 容易误判。别名是否起作用，得看容器最终解析出来的服务映射关系。
执行命令：php bin/console debug:container --types 能列出所有接口及其实现绑定；加 --show-private 可见别名条目。
- 如果
MailerInterface在输出里显示为alias for "App\Service\LegacyMailer"，说明别名已注册成功 - 如果显示为
alias for "App\Service\SymfonyMailerAdapter"，说明有别的配置覆盖了你的定义（比如framework.mailer自动注册了别名） - 别名不会出现在
debug:container mailer这类按 ID 查的结果里，它只影响接口类型的查找
同名服务冲突：当类名和服务 ID 碰巧一样时
Symfony 默认会把类自动注册为服务，ID 就是类名。如果你手动定义了一个同名服务（比如 App\Service\Logger），又同时加了别名 LoggerInterface: '@App\Service\Logger'，容器可能因 ID 冲突拒绝启动。
错误信息典型为：The service "App\Service\Logger" has a dependency on a non-existent service "logger".（其实是循环引用或 ID 解析歧义）
- 避免手动定义与类名完全一致的服务 ID；改用带前缀的 ID，如
app.logger.legacy - 若必须保留类名 ID，需在服务定义中加
autoconfigure: false，防止框架自动添加接口别名 - 别名目标 ID 必须明确存在，不能依赖“类自动注册”+“别名同时生效”的巧合顺序
复杂点在于：别名、自动注册、autoconfigure、bind 四者交织时，哪个先生效、哪个后覆盖，没有文档级明确顺序，只能靠 debug:container 验证结果。别信配置看起来“应该对”，得看容器实际认了什么。
