symfony中trait不参与依赖注入，依赖必须由宿主类在构造函数中声明并注入，trait仅可访问已注入的属性，不可自行获取服务或硬编码容器调用。
在 Symfony 4 中，用 Trait 封装可复用逻辑很常见，但直接在 Trait 里“使用”依赖（比如调用 `$this->logger->info()`）时，必须确保依赖已正确注入到使用该 Trait 的类中——Trait 本身不参与依赖注入流程，它只是代码复制层，不被容器识别或管理。
依赖必须由宿主类声明和接收
Trait 没有构造函数，也不能被容器实例化。所有依赖都得通过使用它的类来注入：
- 宿主类（如 Controller 或 Service）需在构造函数中声明所需依赖，例如 private readonly LoggerInterface $logger
- Trait 内只能访问 $this->logger 这类已由宿主类注入的属性，不能自行声明或初始化
- 若宿主类用了 setter 注入或属性注入，也需确保该属性在 Trait 调用前已被赋值
避免在 Trait 中硬编码服务获取逻辑
不要在 Trait 里写 $this->container->get('logger') 或 $this->get('logger')：
- 这绕过依赖注入原则，破坏可测试性，且在无 ContainerInterface 的上下文中会报错
- Symfony 4+ 默认禁用控制器对容器的直接访问（
ContainerAwareInterface已废弃） - 若真需动态获取服务，应由宿主类提供委托方法，或改用工厂/策略模式
类型安全与自动装配需对齐宿主类配置
Trait 中使用的依赖类型，必须与宿主类的自动装配条件一致：
- 宿主类构造函数要有准确类型提示（如 LoggerInterface），且该接口已在服务定义中绑定实现
- 若多个服务实现同一接口（如两个 LoggerInterface），需用 bind 或 @Autowire 明确指定，否则 Trait 运行时可能拿到意料之外的服务实例
- 标量参数（如 string $apiToken）无法靠自动装配解决，必须由宿主类在
arguments:或bind:中显式传入
推荐做法：把 Trait 当作“能力增强器”，而非“服务消费者”
更清晰、可维护的方式是让 Trait 只定义行为，依赖由宿主明确提供：
- 定义一个方法如 logAction(string $message)，内部调用 $this->logger->info($message)
- 宿主类负责注入 $logger，并确保其非 null（可通过构造函数强制）
- 必要时可在 Trait 中加运行时检查：if (!$this instanceof LoggerAwareInterface) { throw new \LogicException(...); }
