不能在 handle() 里 new Service，因为会绕过容器导致无法享受单例、生命周期管理、AOP 等能力，且内部依赖无法自动解析、测试困难；应通过构造函数类型提示注入或 $this->app->make() 获取。
直接用 $this->app->make() 或类型提示注入，别在 handle() 里 new
为什么不能在 handle() 里 new Service？
TP8 的控制台命令（think\console\Command）默认由容器管理，但 handle() 方法本身不自动触发依赖注入——它只是普通方法调用，不是控制器动作或事件监听器。如果你手动 new UserService()，就绕过了容器，导致：
- 无法享受单例、生命周期管理、AOP（如日志、事务代理）等容器能力
- Service 内部依赖（比如
Db、Cache、Request）不会被自动解析，可能报BindingResolutionException - 测试困难：无法轻松 mock 依赖
推荐做法：在构造函数中声明依赖
TP8 容器会扫描命令类构造函数的类型提示，并在实例化命令时自动注入。这是最干净、最符合框架设计的方式。
示例：
namespace app\command;
use app\service\UserService;
use think\console\Command;
use think\console\Input;
use think\console\Output;
class SyncUserCommand extends Command
{
protected $userService;
public function __construct(UserService $userService)
{
$this->userService = $userService;
parent::__construct();
}
protected function configure(): void
{
$this->setName('task:sync-user')
->setDescription('同步用户数据');
}
protected function handle(Input $input, Output $output): int
{
// 直接用，已注入完毕
$this->userService->syncAll();
return self::SUCCESS;
}
}
备用方案：手动从容器取（适合动态/条件性依赖）
如果依赖不确定（比如根据参数决定用哪个 Service），可在 handle() 中显式调用容器：
- 用
$this->app->make(UserService::class)—— 推荐，语义清晰，支持单例缓存 - 避免用
app()->make()全局函数，它在命令上下文中可能未初始化完整（尤其早期 TP8 版本） - 不要用
new UserService()+ 手动传参，破坏解耦
注意：$this->app 在 Command 基类中已自动注入，无需额外处理。
常见失败原因：服务类没注册或没加载
即使写了构造函数注入，仍报 “Class not found” 或 “Unresolvable dependency”，大概率是以下任一：
-
UserService类文件未被自动加载器识别（检查composer.json的"autoload": {"psr-4": {...}}是否包含其命名空间） - 该类未实现可实例化的构造函数（例如含未提供默认值的必填参数，或依赖未绑定的抽象接口）
- 服务类用了
__invoke但没正确配置为可调用绑定（一般不需要，除非你主动 bind 了闭包）
调试时加 php think schedule:run -v，看是否卡在 service 实例化环节——错误堆栈里通常会暴露具体哪个类没找到或构造失败。
真正容易被忽略的是：命令类必须由容器创建，而不是 new SyncUserCommand() 手动实例化。所有通过 php think xxx 调用的命令，都走容器流程；但如果你在其他地方（比如中间件、事件回调）手动 new 命令类，注入就完全失效。
