典型现象是ArgumentCountError或依赖为null，根本原因是手动new控制器绕过服务容器，导致类型提示无法解析；正确做法是通过路由访问或app()获取实例，并确保接口绑定正确且实现类显式implements接口。
构造函数注入报错的典型现象
最常见的错误是 ArgumentCountError: Too few arguments to function App\Http\Controllers\DemoController::__construct()，或者依赖属性为 null 导致后续调用失败（如 $this->service->getNumber() 报 Call to a member function on null）。
根本原因不是 Laravel “不支持注入”，而是控制器没被容器创建——比如你手动写了 new DemoController()，或在事件监听器、命令类里直接 new 控制器实例；又或者路由用了已弃用的字符串语法（'DemoController@index'），导致 Laravel 跳过自动解析流程。
- 检查路由是否用数组语法：
Route::get('/demo', [DemoController::class, 'index'])✅，而不是字符串'DemoController@index'❌（Laravel 6+ 已弃用） - 确认控制器类名以
Controller结尾，且命名空间与文件路径一致（如app/Http/Controllers/DemoController.php对应App\Http\Controllers\DemoController） - 构造函数必须是
public，不能是protected或private，否则容器无法实例化
正确写法：类型提示 + 容器自动解析
Laravel 6 支持构造函数自动注入，前提是控制器由路由调度或 app() 创建。不需要显式绑定，只要类型提示写对即可：
use App\Services\DemoService;
class DemoController extends Controller
{
protected $service;
public function __construct(DemoService $service)
{
$this->service = $service;
}
public function index()
{
return response()->json(['number' => $this->service->getNumber()]);
}
}
-
DemoService必须是可实例化的类（无未满足的依赖，或其依赖也能被容器解析） - 如果
DemoService构造函数有参数（如HttpClient $client），确保HttpClient本身也已注册进容器（Laravel 内置类默认已绑定） - 不要在构造函数里调用
parent::__construct()—— Laravel 的Controller基类构造函数为空，加了反而可能干扰
接口绑定失败：implements 比 bind() 更关键
如果你用接口类型提示（如 DemoContract $service），但报 Target [App\Contracts\DemoContract] is not instantiable，问题往往不在绑定本身，而在实现类没真正实现该接口。
PHP 的类型约束在运行时强制校验，仅靠容器绑定无法绕过：
- 实现类必须显式
implements DemoContract，且方法签名（参数名、类型、默认值）必须与接口完全一致 - 在
AppServiceProvider@register()中绑定：$this->app->bind(DemoContract::class, DemoService::class) - 验证是否生效：在
tinker中运行app(App\Contracts\DemoContract::class)，看是否返回实例 - 若接口方法定义了
array $options = []，实现类里也必须写成array $options = []，少一个等号都会触发TypeError
测试时 Mock 不生效？别手动 new
在 Feature 测试中，如果写 $controller = new DemoController(new MockDemoService())，Mock 一定无效——因为 Laravel 的 mock() 或 partialMock() 是通过覆盖容器绑定来拦截的，只对容器解析的对象起作用。
- 测试必须走真实路由访问：
$response = $this->get('/demo')，让容器创建控制器并注入依赖 - Mock 要在请求前注册：
$this->mock(DemoService::class)->shouldReceive('getNumber')->andReturn(42) - 如果服务类有构造参数，Mock 时需确保参数能被容器解析，否则
mock()会因无法实例化原类而失败 - 避免在测试中用
app(DemoController::class)—— 它虽能触发注入，但绕过了中间件和请求生命周期，行为与真实请求不一致
真正容易被忽略的是：构造函数注入只在容器创建对象时发生一次，之后所有方法调用共享同一个依赖实例。如果这个依赖内部有状态（比如缓存了某次查询结果），而你又在多个测试里复用它，就可能产生隐性耦合——这不是注入机制的问题，而是设计层面需要留意的点。
