别名是强制指定接口默认实现的机制，仅影响$container->get()调用，不参与autowire；必须定义在services根层级，目标服务须已存在，且不可含class等字段，重复定义时后加载者生效。
别名不是“起个别名方便写”，而是强制指定某个接口的默认实现，只影响 $container->get(MyInterface::class) 这种类型获取，不参与 autowire。
别名必须写在 services 根层级
常见错误是把别名塞进某个服务的 arguments 或 bind 块里，比如：
services:
App\Service\ReportGenerator:
arguments:
$logger: '@App\Service\FileLogger'
# ❌ 下面这行完全被忽略
App\Contract\LoggerInterface: '@App\Service\FileLogger'正确位置只能是 services: 下一级：
services: # ✅ 正确：根层级定义 App\Contract\LoggerInterface: '@App\Service\FileLogger' <p>App\Service\ReportGenerator: arguments: ['@App\Contract\LoggerInterface']
- 目标服务 ID（如
App\Service\FileLogger）必须已存在——要么自动注册，要么你已在 YAML 中显式声明过 - 别名不能是未注册的类名，比如
App\Service\MissingLogger没定义过，就会报错“Service not found” - 别名本身不能带
class:、public:等字段，它只是个指向
别名覆盖规则：后定义生效，但跨文件靠字母序
同名别名重复定义时，后加载的会覆盖前面的。但如果你把别名分散在多个 YAML 文件中（比如 packages/logging.yaml 和 packages/payment.yaml），Symfony 加载顺序取决于文件名的字母顺序，不是按你在 config/services.yaml 里写的先后。
- 推荐统一写在
config/services.yaml底部，避免不可控覆盖 - 注意 FrameworkBundle 自动注册的别名（如
mailer→symfony.mailer）可能静默覆盖你的定义 - 运行
php bin/console debug:container --types | grep LoggerInterface可确认最终生效的是哪个
别名不解决 autowire 多实现冲突
当你有 StripeProcessor 和 PaddleProcessor 都实现了 PaymentProcessorInterface，只设别名：
App\Contract\PaymentProcessorInterface: '@App\Service\StripeProcessor'
并不能让 __construct(PaymentProcessorInterface $p) 成功注入——autowire 仍会报 “Multiple services exist”。
- 必须显式禁用该接口的 autowire：
services: App\Contract\PaymentProcessorInterface: ~ autowire: false - 或在具体服务中用
bind指定：bind: $processor: '@App\Service\StripeProcessor' - 别名只对
$container->get(PaymentProcessorInterface::class)有效，autowire 是另一套匹配逻辑
验证别名是否真正注册成功
别名写对了 ≠ 容器里真有。最可靠的方式是查容器实际解析结果：
php bin/console debug:container --types | grep PaymentProcessorInterface
如果输出类似 alias for "App\Service\StripeProcessor"，说明注册成功；如果没出现、显示另一个实现、或提示 “no services found”，就说明：
- 别名写错位置（嵌套在别的块里）
- 目标服务 ID 不存在（拼错类名、没启用自动注册、或类路径不对）
- 被其他文件里的同名别名覆盖了（尤其检查
vendor/symfony/framework-bundle自带的 alias）
别名机制本身很简单，但失效原因几乎都出在配置层级和加载顺序上，而不是语法错误。
