Laravel 5.5 构造函数注入由服务容器通过 ReflectionClass 显式解析触发：调用 make() 读取 __construct() 签名，递归解析类型提示参数；未绑定接口需手动 bind() 或 singleton()，否则报 Target is not instantiable；方法参数注入按声明顺序匹配路由与类型规则，顺序错误会导致基础类型被误判为模型而报错。
Laravel 5.5 的依赖注入不是“自动 magic”，而是由 Illuminate\Container\Container 实例驱动的、基于反射（Reflection）的显式解析过程——理解这点，才能避开“为什么没注入”“为什么报错”的多数坑。
构造函数注入是怎么被触发的？
当你访问一个控制器方法（比如 UserController@show），Laravel 并不是直接 new 出控制器实例，而是调用服务容器的 make() 方法去解析它。这个过程会：
- 读取控制器类的
__construct()签名，用 PHP 的ReflectionClass获取参数类型提示 - 对每个带类型提示的参数（如
UserService），递归调用make()尝试解析其具体实现 - 如果该类未被显式绑定，且存在无参构造函数，就直接 new；否则抛出
BindingResolutionException
注意：Request、Response 这类框架内置类能“自动注入”，是因为它们在 Application 启动时已被 singleton() 或 bind() 预注册进容器，不是靠“魔法识别”。
方法参数注入和路由绑定混在一起容易踩什么坑？
Laravel 5.5 的控制器方法参数注入（如 public function show(User $user, $page = 1)）实际是两套逻辑叠加的结果：
- 若参数类型实现了
UrlRoutable（比如 Eloquent 模型），则优先从路由参数（如{user}）中提取 ID，查库并注入模型实例 - 若参数是基础类型（
string、int）且变量名匹配路由占位符（如$page对应{page?}），则取路由值 - 但顺序敏感：写成
show($page, User $user)会导致$page被当成模型主键去查库，报Class page does not exist错误
这不是 bug，是设计限制——Laravel 不做命名匹配，只按声明顺序依次匹配路由参数 + 类型规则。
什么时候必须手动 bind()？
当你要注入的不是具体类，而是接口或抽象类时，容器无法凭空知道该用哪个实现。比如：
interface PaymentGateway
{
public function charge();
}
class StripeGateway implements PaymentGateway { ... }
class AlipayGateway implements PaymentGateway { ... }
这时必须在服务提供者的 register() 方法里明确告诉容器：
-
$this->app->bind(PaymentGateway::class, StripeGateway::class);—— 每次解析都返回新实例 -
$this->app->singleton(PaymentGateway::class, AlipayGateway::class);—— 全局单例
漏掉这步，new Controller(PaymentGateway $gateway) 会直接报 Target [PaymentGateway] is not instantiable。
循环依赖报错怎么快速定位？
ContextErrorException: Maximum function nesting level of '100' reached 或 Circular dependency detected 通常意味着 A 依赖 B，B 又依赖 A（哪怕间接）。
- 检查构造函数链：A → B → C → A？常见于 Repository 和 Service 互相持有
- 避免在构造函数里调用对方方法（如
$this->userService->syncProfile()），改用方法注入或事件触发 - 临时加日志：在
Container::resolve()中打点，看解析路径是否成环
真正难缠的不是“不能写循环依赖”，而是它往往藏在三层以上的调用链里，靠报错堆栈一眼看不出源头。
