服务容器是laravel应用启动后持续运行的核心机制，通过反射解析类型提示并递归make依赖，bind每次新建实例，singleton全局单例；接口需显式绑定，未类型提示参数被跳过，自动注入仅限框架入口点。
服务容器不是“要用才学”的工具，而是 Laravel 应用启动后就一直在背后工作的核心机制——你写的每个控制器、中间件、Job，只要用了类型提示，就已经在用它了。
构造函数注入为什么能自动生效
因为 Laravel 在路由分发时调用 $route->runController($request)，内部会触发 $this->resolveClassMethodDependencies()，该方法通过 PHP 的 ReflectionClass 读取构造函数参数的类型提示，再递归调用 $container->make() 实例化每个依赖。
- 依赖必须是具体类或已绑定的接口，否则解析失败报
Target class [xxx] does not exist - 如果某依赖的构造函数也有类型提示，容器会继续递归解析，直到所有依赖都满足
- 未声明类型提示的参数（如
$id）会被跳过，不参与自动注入 - 构造函数里混用类型提示和普通参数没问题，容器能区分：例如
__construct(UserRepository $repo, $id)中只注入$repo
bind() 和 singleton() 的实际区别
两者都注册解析规则，但生命周期不同：bind() 每次 make() 都新建实例；singleton() 只创建一次，后续返回缓存实例。
- 适合单例的典型场景：数据库连接、日志实例、配置管理器——它们状态共享且开销大
- 误把高并发下需隔离状态的服务（如带用户上下文的请求处理器）注册为单例，会导致数据串扰
- 接口绑定必须显式调用
bind()，比如$this->app->bind(LoggerInterface::class, MonologLogger::class)，否则容器不知道该用哪个实现 - 绑定发生在服务提供者的
register()方法中，不能晚于容器开始解析依赖的时间点
方法注入在控制器里怎么避免参数顺序出错
控制器 action 方法支持类型提示注入（如 Request、FormRequest），但路由参数（如 {id}）和注入对象共存时，Laravel 依靠反射 + 路由参数名双重匹配，不是靠位置。
- 写法安全：把类型提示参数放前面，路由变量放后面，例如
store(StoreUserRequest $form, $id) - 危险写法：把路由变量写成类型提示形参名但没对应类型，比如
show($user)—— 容器会尝试解析$user为类，报Target class [user] does not exist - FormRequest 注入会自动触发验证，且验证失败时直接返回 422，无需手动调
$request->validate() - 自定义类方法注入仅在路由调度链中有效；在命令行、队列 Job 或手动 new 的对象里调用该方法，不会触发自动注入
什么时候必须手动 app()->make()
自动注入只发生在框架可控的入口点（控制器、中间件、事件监听器、Job 构造函数等）。遇到以下情况，就得显式调用：
- 在非容器管理的类（比如普通工具类、DTO、静态方法）里需要某个服务
- 条件性获取：比如根据配置决定用
RedisCache还是FileCache，而没做接口绑定 - 临时一次性使用，不想污染构造函数签名（如日志记录中临时取
Config值） - 注意：
app()->make()不等于new，它仍走绑定逻辑和单例判断，但绕过了自动解析的上下文约束
最常被忽略的一点：服务容器的绑定和解析行为高度依赖类的自动加载是否就绪。如果在 register() 里绑定一个尚未被 Composer 自动加载的类，make() 时会静默失败或抛出找不到类的错误——务必确保绑定目标类已声明命名空间且可被 PSR-4 正确定位。
