Symfony命令类默认注册为容器服务，支持构造函数依赖注入，应避免在execute中手动获取服务或编写业务逻辑，而应通过独立服务类实现功能复用与测试性。
Symfony 命令类天然支持依赖注入，不用手动 new 服务，也不用从容器里 get，只要声明类型提示，容器就自动塞进来——这是解耦和可维护性的起点。
命令类本身就是服务
Symfony 把每个命令类（继承 Command 的类）默认注册为服务。它不是普通 PHP 脚本，而是容器管理的组件。这意味着：
- 它能像其他服务一样接收依赖
- 不需要在 execute() 里调用 $this->getContainer()->get('...')
- 不再出现硬编码的 new SomeService()
构造函数注入是标准做法
把所需服务作为构造函数参数声明，用接口类型提示，让容器自动解析：
- 写法示例：
public function __construct(private LoggerInterface $logger, private UserRepository $userRepository) - 容器会根据类型自动匹配已注册的服务（比如
monolog.logger或你自定义的App\Repository\UserRepository） - 不推荐在
execute()中临时获取依赖，那会隐藏真实依赖，也破坏测试性
避免在命令中做业务逻辑搬运工
命令只负责“调度”，不负责“实现”。常见反模式是把数据库查询、API 调用、文件处理全塞进 execute() 方法里。正确方式是：
- 把具体工作抽成独立服务类（如 UserExportService）
- 在命令构造函数中注入该服务
- execute() 只调用 $this->exportService->run($input)
- 这样服务可被控制器、事件监听器、其他命令复用，也方便单独测试
按需配置服务可见性与参数
如果命令需要差异化行为（比如开发环境导出 CSV，生产环境发邮件），不要写 if 判断，而是：
- 用配置参数控制行为：arguments: ['%app.export_format%']
- 或注入不同实现：通过接口 + 多个实现 + 标签（app.exporter.csv, app.exporter.email）+ 修饰器或工厂
- 在 config/services.yaml 中明确设置命令服务的 public: false（默认已是），防止被意外从容器直接调用
