自定义 bin/magento 命令运行时报 Area code is not set，很多示例会建议在任意位置调用 setAreaCode('adminhtml')。这有时能让异常消失，却可能把错误区域固定到构造阶段，影响其他 CLI 命令、测试和长进程。

Area 决定哪些配置和设计被加载

Magento 的 frontend、adminhtml、crontab、webapi_rest、graphql 等 area 会影响事件、DI 配置、翻译和布局。CLI 本身没有天然的前台或后台上下文。只有当命令使用需要特定 area 的服务时，才需要明确设置或模拟。

不要在构造函数中设置 Area

Symfony Console 启动时会实例化多个命令。一个命令在构造函数里设置 adminhtml，可能导致另一个命令再设置时抛 Area code is already set。应在当前命令的 execute() 中、真正使用相关服务前处理。

try {
    $this->state->setAreaCode(Area::AREA_ADMINHTML);
} catch (LocalizedException $exception) {
    // 仅在已经由当前运行上下文设置时决定是否继续
}

不要无条件吞掉异常。Area 已被设置成 frontend 与已设置成 adminhtml 的含义不同，命令应明确自己需要什么。

更小的边界可以使用 emulateAreaCode

如果只是一段代码需要特定区域，可以用 App State 的 area 模拟包装回调，让执行结束后恢复原状态。它比在长进程一开始永久设置更安全，尤其是消费者或一次处理多个 Store 的命令。

不过 area 模拟不会自动切换 Store。邮件模板、价格、URL 和配置读取还可能依赖 Store Manager，需要分别设置明确的 Store 上下文，并在循环后恢复。

异常往往暴露了不适合 CLI 的依赖

命令如果注入 Block、Layout、Session 或依赖 HTTP 请求的类，很容易要求 area。把核心业务提取到不依赖展示层的 service，CLI、Cron 和 API 都能复用。命令只负责解析参数、选择 Store、调用服务和返回退出码。

不要用 ObjectManager 临时创建服务

运行到一半才通过 ObjectManager 取对象，会隐藏依赖并让 area 初始化顺序更难控制。使用构造注入和明确的 service contract，单元测试也能覆盖。

修复后从全新的 CLI 进程运行命令，再连续运行其他核心命令，确认没有污染全局 State。测试不同 Store、异常重试和长批次，确保区域与商店上下文在每次迭代中一致。