Symfony CLI命令需显式注册到Application实例才能被识别；类须继承Command、命名以Command结尾、参数选项需正确配置，默认值和布尔判断易出错；依赖须构造注入，禁用getContainer()；返回值必须用Command::SUCCESS/FAILURE。
直接用 symfony/console 就能写可维护、可测试、带参数校验和依赖注入的 CLI 工具，不用自己 parse $argv 或手写 help 文本。
怎么注册一个命令并让 bin/console 认得它
不是把类文件放对位置就自动生效——必须显式注册进 Application 实例。Symfony 项目默认在 bin/console 里完成这一步；如果你是独立使用（没用框架），就得自己写：
#!/usr/bin/env php <?php require_once __DIR__.'/../vendor/autoload.php'; use App\Command\ImportUsersCommand; use Symfony\Component\Console\Application; $application = new Application(); $application->add(new ImportUsersCommand()); $application->run();
-
ImportUsersCommand类必须继承Command，且放在src/Command/下（路径不强制，但类要能被自动加载） - 别漏掉
$application->add()，否则php bin/console list里根本看不到你的命令 - 类名必须以
Command结尾，否则 Doctrine、MakerBundle 等工具扫描时会跳过
configure() 里加参数和选项的常见翻车点
很多报错都源于这里：比如 --force 总是 null，或 php bin/console app:deploy prod 提示 “not enough arguments”。
- 必需位置参数要用
InputArgument::REQUIRED显式声明：$this->addArgument('env', InputArgument::REQUIRED)，否则$input->getArgument('env')永远返回null - 布尔选项（如
--dry-run）默认值是null，不是false；判断时写$input->getOption('dry-run') === true，别用empty()或! - 带默认值的选项，第 5 个参数才是默认值：
$this->addOption('timeout', null, InputOption::VALUE_REQUIRED, '', 30)；漏掉空字符串说明（第 4 个参数）会导致 help 文本缺失描述 - 参数含空格必须加引号：
php bin/console app:ban-user "John Doe"，否则 shell 只传John
在 execute() 里安全调用服务和数据库
CLI 环境没有请求上下文，硬调 HTTP 相关服务会直接抛 LogicException。
立即学习“PHP免费学习笔记（深入）”；
- 依赖必须通过构造函数注入，比如
public function __construct(private EntityManagerInterface $em)；别在execute()里调$this->getContainer()—— 这是 Symfony 4.0 前的写法，已弃用 - Doctrine 实体管理器优先用
EntityManagerInterface类型提示，而不是字符串 ID（如doctrine.orm.default_entity_manager），后者在容器里可能根本不存在 - 像
RequestStack、SessionInterface、UrlGeneratorInterface这类强依赖 HTTP 生命周期的服务，在命令里基本不可用，提前检查接口契约，别等运行时报错才改 - 返回值必须是
Command::SUCCESS或Command::FAILURE（整数常量），别直接return 0或return 1—— 单元测试断言会失败
最常被忽略的是：命令类的生命周期完全由 Application 控制，它不共享 Web 请求的 service container scope。哪怕你用了相同的依赖注入配置，CLI 命令里的服务实例也可能是全新创建的，事务、缓存、连接池行为都可能和 Web 请求不同。调试前先确认你查的是哪个容器实例。
