控制器手动new会绕过容器导致依赖注入失效，典型报错argumentcounterror源于未走路由或app()调用；正确做法是通过路由访问或app(democontroller::class)触发自动解析。
控制器里手动 new 一个服务类，依赖注入就彻底失效了——这不是配置问题，是绕过了容器本身。
构造函数注入失败：ArgumentCountError 怎么快速定位
典型报错：ArgumentCountError: Too few arguments to function App\Http\Controllers\DemoController::__construct()。这不是代码写错了，而是你用 new DemoController() 实例化控制器，Laravel 容器根本没机会介入。
- 检查调用链：是否在事件监听器、Artisan 命令、或旧逻辑里写了
new DemoController(new SomeService()) - 确认入口：只有通过路由访问（如
GET /demo）或app(DemoController::class)才触发自动解析 - 别信 IDE 提示：构造函数参数标红不等于代码错误，而是容器没运行到那一步
app() 和 $this->resolve() 在控制器里能混用吗
能，但语义和前提完全不同。误用会直接抛出 Call to a member function resolve() on null。
-
app(SomeService::class)：安全，任何时候都可用，每次调用新建实例 -
$this->resolve(SomeService::class)：仅当控制器由容器创建（即走正常路由）时才有效；手动 new 的控制器里$this->container是null - 性能上差异可忽略，但过度用
app()在方法里取服务，往往说明该依赖本该走构造函数注入
接口绑定后仍报 Target [...] is not instantiable
不是 bind 写错了，是绑定没生效或实现类本身有未解依赖。
- 检查绑定位置：必须在
AppServiceProvider::register()中，不能放在boot() - 绑定写法必须用 FQCN 或
::class常量，比如$this->app->bind(PaymentGateway::class, AlipayGateway::class)，字符串形式（如'App\Contracts\PaymentGateway'）无法自动解析 - 验证实现类构造函数：如果
AlipayGateway依赖HttpClient，而HttpClient没被容器识别，绑定后仍会失败 - 开发期快速验证：
php artisan tinker里执行app(App\Contracts\PaymentGateway::class)，看是否返回实例
Form Request 自身需要依赖服务怎么办
Form Request 不是控制器，但它也支持构造函数注入——前提是它被容器解析，而 Laravel 默认只对控制器、中间件、Job 等做自动解析。Form Request 默认不走容器，需显式启用。
- 在 Form Request 类里声明构造函数依赖，例如
public function __construct(private Cache $cache) - 但默认情况下，
StorePostRequest是被ValidatorFactory直接 new 出来的，不会触发容器解析 - 解决办法：在
rules()或withValidator()里用app(Cache::class)按需获取，或改用方法注入（如把Cache作为authorize()方法参数） - 注意：不要在
authorize()里用$this->resolve()，因为此时$this->container还未初始化
最常被忽略的点：控制器方法参数注入（比如 StorePostRequest $request）和构造函数注入是两套机制，前者由验证器管道驱动，后者由容器驱动；它们共存但互不干扰，别指望在 Form Request 里用 $this->resolve() —— 它压根没经过容器生命周期。
