target is not instantiable 错误源于接口未绑定或无法推导实现类，主因包括boot()中绑定、契约未注册、类型提示错误、implements缺失或签名不匹配；bind()用于有状态对象，singleton()用于无状态服务；自定义contract需严格遵循命名空间、实现、注册位置及测试规范。
Contract 注入失败：Target is not instantiable
这是最常遇到的报错，比如 Target [Illuminate\Contracts\Cache\Repository] is not instantiable。它不表示 Laravel 容器坏了，而是你试图解析一个接口，但容器既没找到绑定，也没自动推导出实现类。
常见诱因：
- 在
boot()方法里调用bind()或singleton()—— 此时容器已冻结，绑定被忽略 - 自定义 Contract 接口没在
AppServiceProvider::register()中显式绑定 - 用了 Facade（如
Cache::get()）或辅助函数，却误以为这等价于契约注入 - 类型提示写的是具体类（如
Illuminate\Cache\Repository），而非契约接口（Illuminate\Contracts\Cache\Repository）
implements 缺失或方法签名不匹配
PHP 的类型系统会在运行前做严格校验：构造函数声明了 BananaFactory $factory，传进来的对象所属类就必须 implements BananaFactory。仅靠容器绑定无法绕过这个检查。
必须确保：
- 实现类明确声明
class StripeOrderProcessor implements \App\Contracts\OrderProcessor - 接口中每个
public方法，在实现类中都存在且签名完全一致（参数名可不同，但类型、数量、默认值必须匹配） - 别在实现里漏掉接口声明的任一方法，哪怕你暂时只用其中两个
bind() 和 singleton() 选错导致状态错乱
绑定方式不是风格偏好，而是行为差异。Laravel 6 的容器对生命周期控制很敏感，选错会直接引发数据污染或连接泄漏。
bind() 适合：
- 每次请求都需要干净上下文的对象，比如表单验证器、临时 DTO 构造器
- 依赖
Request、Auth::user()或 session 的服务 —— 复用实例会导致后续请求拿到上一个用户的 session 数据
singleton() 适合：
- 无状态、资源型服务，如 Redis 客户端、日志记录器、UUID 生成器
- 自定义缓存实现（如
MyCustomCache），必须用singleton()，否则每次app()->make()都新建连接，可能耗尽 Redis 连接池
⚠️ 特别注意：singleton() 实例在 Artisan 命令或队列任务中不会自动刷新 —— 如果它内部缓存了用户 ID 或请求路径，后续任务会复用旧值。
自定义 Contract 时最容易被忽略的细节
自己定义契约不是建个 interface 文件就完事。真正让契约生效的，是它和实现、绑定、使用三者之间的咬合关系。
务必检查：
- 接口文件放在
app/Contracts/下，命名空间与文件路径严格对应（如App\Contracts\Notifier→app/Contracts/Notifier.php） - 实现类必须
implements该接口，且所有方法都完整实现 —— 即使某些方法抛出NotSupportedException，也得写出来 - 绑定语句写在
AppServiceProvider::register()，不能写在boot()；若需根据环境切换实现，用闭包 +app()->environment()判断，不要用if (env()) - 测试时，mock 的是 Contract 接口本身（
$this->mock(\App\Contracts\Notifier::class)），而不是实现类 —— 否则测试就失去了契约解耦的意义
复杂点在于：契约一旦定义，就锁定了方法签名。改一个参数类型或加个可选参数，所有实现类和调用处都得同步更新。这不是 Laravel 的限制，而是接口契约本身的刚性 —— 它保证了替换实现时的“零感知”，代价就是定义阶段得多花两分钟想清楚。
