Laravel依赖注入失效的根本原因是手动new绕过了服务容器，导致类型提示无法解析；正确做法是通过路由访问或app()获取实例，并确保接口绑定正确。
为什么 __construct 里 new 一个类会破坏 Laravel 的依赖注入
因为 Laravel 的容器只对通过路由解析或 app() 获取的控制器实例做自动注入，手动 new 就绕过了容器，所有类型提示（SomeService $service）直接报错或为 null。
- 典型错误现象：
ArgumentCountError: Too few arguments to function AppHttpControllersDemoController::__construct() - 真实场景：在事件监听器、命令类、或旧代码迁移时手写
new DemoController(new SomeService()) - 正确做法：让 Laravel 自己创建控制器——要么走路由访问，要么用
app(DemoController::class)，它会递归解析全部依赖 - 注意：
app()每次调用都新建实例，不是单例；如需复用，应绑定到容器并设为 singleton
resolve() 和 app() 在控制器里手动取服务的区别
两者都能从容器拿实例，但语义和时机不同：app() 是全局入口，resolve() 是当前容器实例的方法，常用于构造函数已执行后补依赖。
-
app(SomeService::class)：安全，推荐在方法内按需获取，尤其适合条件性加载（比如只在store()里用） -
$this->resolve(SomeService::class)：仅当控制器本身由容器解析（即正常路由进入）才可用；否则$this->container为null，抛出Call to a member function resolve() on null - 性能影响极小，但过度使用
app()可能掩盖设计问题——该注入的依赖，别藏在方法里临时取
接口绑定失效？检查 AppServiceProvider::register() 里的 bind() 是否写对了
控制器构造函数写的是接口类型提示，但容器不知道该用哪个实现类，必须显式绑定，否则报 Target [AppContractsPaymentGateway] is not instantiable。
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 常见错误：绑定写成
$this->app->bind('App\Contracts\PaymentGateway', ...)，但字符串写法不支持自动解析，必须用 FQCN（完整命名空间）或 PHP 8.0+ 的::class常量 - 正确写法：
$this->app->bind(PaymentGateway::class, AlipayGateway::class) - 如果实现类也有依赖（比如需要
HttpClient），确保它的构造函数参数也能被容器解析，否则绑定后仍会失败 - 开发期可运行
php artisan tinker测试：app(AppContractsPaymentGateway::class)看是否返回实例
控制器方法参数自动注入 vs 构造函数注入：选哪个
都可行，但用途不同。构造函数注入适合整个控制器生命周期都需要的对象（如仓储、网关）；方法注入适合只在某个动作里用、且可能带运行时参数的服务（如表单请求验证器、策略实例）。
- 方法注入示例：
public function update(UpdatePostRequest $request, Post $post)——$request是自动实例化的表单请求类，$post是隐式路由模型绑定 - 不能混用：方法参数里写
SomeService $service不会自动解析，Laravel 只对FormRequest和模型绑定做方法级注入，其他一律走构造函数 - 如果某服务只在两个方法里用，又不想污染构造函数，可考虑在方法内用
app()拿，比强行塞进构造函数更轻量
最常被忽略的是：依赖注入生效的前提是控制器必须由 Laravel 容器管理。任何绕过路由、手动 new、或在非容器上下文（比如单元测试里直接 new 控制器）的操作，都会让类型提示失效——这不是配置问题，是机制使然。
