构造函数注入能“自动工作”是因为Laravel服务容器通过ReflectionClass扫描构造函数类型提示，递归解析并实例化依赖；未类型提示的必填参数会导致Unresolvable dependency错误，标量类型无法自动注入，接口等需手动bind或singleton绑定。
构造函数注入是 Laravel 里最稳定、最可预测的依赖注入方式，只要类型提示明确、类可自动解析，就能零配置生效。
构造函数注入为什么能“自动工作”
Laravel 的服务容器在实例化类时，会用 PHP 的 ReflectionClass 扫描构造函数参数，逐个检查类型提示（如 UserService、Request），然后递归解析这些依赖。这个过程不依赖手动绑定——前提是目标类没有不可推断的参数（比如无类型提示的字符串、数组）。
常见错误现象：
- 报错
Unresolvable dependency resolving [Parameter #0 [ <required> string $token ]] in class App\Services\TokenValidator</required>：说明构造函数里有未类型提示的必填参数，容器无法猜出该传什么 - 注入的是空实例或报
Target class [xxx] does not exist：类路径写错，或文件没被自动加载（composer dump-autoload没跑）
哪些类型能被直接注入
以下几类无需提前 bind() 就能直接使用构造函数注入：
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 具体类（如
UserService、MailManager），只要类存在且可自动加载 - Laravel 自带的契约（如
Illuminate\Contracts\Cache\Repository），框架已预绑定 - HTTP 相关类（
Request、Response、UploadedFile）在控制器中可直接注入 - 路由模型绑定变量（如
public function show(User $user)中的$user是方法注入，但原理类似）
注意：string、int、array 等标量类型不能自动注入，必须显式绑定或改用方法注入 + 参数解构。
什么时候必须提前 bind() 或 singleton()
当你需要控制实现类、生命周期或上下文行为时，就得手动绑定：
- 接口注入：比如
UserRepositoryInterface必须在AppServiceProvider::register()里$this->app->bind(UserRepositoryInterface::class, EloquentUserRepository::class) - 单例场景：日志服务、配置管理器这类全局共享实例，用
$this->app->singleton()避免重复初始化 - 带运行时参数的构造：如
new HttpClient(['base_uri' => config('api.base')])，需闭包绑定返回实例 - 第三方类（如
GuzzleHttp\Client）未被 Laravel 预设，也要手动bind()或singleton()
容易被忽略的细节
构造函数注入看着简单，但实际项目里最容易栽在三个地方：
- 父类构造函数没调用
parent::__construct()：自定义基控制器或继承Controller时，如果重写了__construct却忘了调用父级，会导致middleware()、authorizeResource()等功能失效 - 注入了太多依赖：一个构造函数超过 4 个参数，往往意味着职责过重，也增加测试 mock 成本
- 在
__construct里执行业务逻辑（比如查数据库、发请求）：这会让类无法被容器安全重建，也破坏了“构造即创建”的语义；应移至具体方法中
真正关键的不是“能不能注入”，而是“该不该在这个时机注入”。构造函数只负责声明依赖，不负责触发行为——这点一旦模糊，后续调试和测试就会越来越吃力。
