Laravel接口绑定失败的根源是容器未获知实现类，导致“Target [Interface] is not instantiable”；须在AppServiceProvider中用bind()显式绑定接口与实现类，并确保实现类完整实现接口方法。
直接依赖具体类，比如 RedisStore 或 DatabaseQueue，等于把实现细节焊死在业务逻辑里——换缓存驱动要改十几处，写单元测试得绕开真实 Redis 连接，上线前才发现某处 new Mailer() 把 SMTP 配置硬编码进去了。面向接口编程不是“为了设计模式而设计”，是为了解决这些真实、高频、让人半夜改代码的麻烦。
Target [Interface] is not instantiable 错误从哪来
这个报错几乎都发生在你写了类型提示却没让容器知道“该用谁来填这个坑”。比如构造函数里写 public function __construct(Cache\Repository $cache)，但没在 AppServiceProvider::register() 里做绑定，Laravel 就真不知道该 new 哪个类。
-
Cache\Repository是 interface，PHP 不允许new它，容器也没默认绑定（不像Request那种框架级自动解析） - 门面（如
Cache::get()）能跑，是因为它背后走的是静态代理 + 已预设好的绑定；但你在类里手动类型提示接口，就得自己负责绑定 - 别指望 IDE 提示或 PHPStan 能提前发现——这错误只在运行时容器尝试解析时才抛出
bind() 和 singleton() 不是性能选项，是正确性开关
选错就等于让多个请求共享同一个实例，而这个实例里可能存着上一个用户的 $request->ip() 或 Auth::id()。
- 用
bind()：每次从容器解析都新建实例，适合含请求上下文、用户状态、临时数据的类（如OrderValidator、CurrentTenantResolver） - 用
singleton()：全局复用单个实例，只适用于无状态、纯计算类（如UuidGenerator、JsonTransformer） - 判断标准就一条：这个类的属性或方法会不会读取动态请求数据？会 → 必须
bind()
自定义 Contract 时，方法漏实现不会编译报错
PHP interface 只保证“声明存在”，不保证“被调用安全”。你声明了 send()，实现类也实现了，但业务代码某处突然调了 $sender->queue() —— 而你根本没在 Contract 里定义 queue() 方法，PHP 就在运行时甩出 Call to undefined method。
- Contract 是契约，不是文档。它必须覆盖所有会被调用的方法，否则就是失效契约
- IDE 不会标红，静态分析工具（如 PHPStan）默认也不检查接口实现完整性，得靠人工对齐或测试覆盖兜底
- 新增方法后，所有实现类都要同步补全，否则上线就崩——这不是“扩展性好”，是隐性耦合
最常被忽略的一点：Contract 本身不提供任何行为，它只是个空壳。写完 app/Contracts/NotificationSender.php，不绑定、不注入、不测试 mock，它就跟注释没区别。解耦不是靠接口名体现的，是靠每一处 __construct(Contract $x) 后面，都有对应的容器绑定和可替换实现撑住的。
