laravel契约是可选但关键的解耦工具，用于替换实现、单元测试和封装sdk；应优先用契约而非facade或辅助函数，通过容器注入而非new实例，确保接口一致性和运行时切换能力。
Laravel 契约（Contracts）不是必须用的，但当你需要解耦服务实现、做单元测试或替换底层逻辑时，它们就变得关键——直接依赖 Illuminate\Contracts\Mail\Mailer 比硬写 Mail::send() 更可控，也更易 mock。
什么时候该用契约而不是 Facade 或辅助函数
Facade（比如 Mail）本质是静态代理，隐藏了实际实例来源，导致测试困难、无法注入不同实现；而契约是接口，明确约定行为，支持依赖注入和运行时切换实现。
- 你要写可测试的服务类，且涉及邮件、缓存、队列等核心功能
- 项目后期要替换默认缓存驱动（比如从 Redis 换成 DynamoDB），但不想改业务代码
- 封装 SDK 或包，对外暴露稳定接口，不绑定 Laravel 具体实现
- 使用
app()->make()或构造函数注入时，类型提示写契约比具体类更安全
Illuminate\Contracts 下常见契约及对应实现类
契约本身不干活，靠容器绑定的具体实现来执行。例如：
Illuminate\Contracts\Cache\Repository → 默认绑定到 Illuminate\Cache\Repository（背后可能是 FileStore 或 RedisStore）
Illuminate\Contracts\Queue\Queue → 绑定到 Illuminate\Queue\SyncQueue（本地）或 Illuminate\Queue\RedisQueue
你可以在 config/cache.php 或 config/queue.php 中切换驱动，只要实现仍满足契约方法签名，上层代码完全无感。
- 查看所有契约：翻
vendor/laravel/framework/src/Illuminate/Contracts/目录 - 不要自己 new 契约实现类，一律通过容器解析：
app(\Illuminate\Contracts\Mail\Mailer::class) - 自定义实现时，必须实现契约中全部
public方法，哪怕只用其中 2 个
在 Service 类里正确注入契约
别在构造函数里写 MailManager 或 Mailer 这种具体类名，那是反模式。
// ✅ 正确：面向接口
class OrderNotifier
{
public function __construct(
protected \Illuminate\Contracts\Mail\Mailer $mailer,
protected \Illuminate\Contracts\Cache\Repository $cache
) {}
}
// ❌ 错误：绑定到具体类，失去替换能力
public function __construct(\Illuminate\Mail\Mailer $mailer) { ... }
- Laravel 自动将契约解析为对应实现，无需额外 bind（除非你换实现）
- PHP 8+ 支持属性提升构造函数，
protected+ 类型提示即可完成注入 - 如果 IDE 提示“cannot resolve”，检查是否漏了
use契约全路径，或是否在非容器管理的上下文（如普通 new 实例）中调用
自己定义契约并绑定实现的最小闭环
当你封装第三方支付 SDK，又想保留未来换供应商的能力，可以这么做：
// app/Contracts/PaymentGateway.php
interface PaymentGateway
{
public function charge(string $orderNo, float $amount): array;
public function refund(string $transactionId): bool;
}
// app/Providers/AppServiceProvider.php → register() 方法内
$this->app->bind(\App\Contracts\PaymentGateway::class, function ($app) {
return new \App\Services\AlipayGateway(
$app->make('config')->get('payment.alipay')
);
});
- 绑定后，任何地方用
app(\App\Contracts\PaymentGateway::class)或构造注入都能拿到AlipayGateway - 切微信支付？只需改 bind 的第二个参数为
WechatGateway，其他代码不动 - 注意：契约方法返回值类型、参数顺序、是否抛异常，都得和所有实现保持一致，否则运行时才报错
契约真正的复杂点不在定义，而在维护一致性——一旦多个实现共用一个契约，增删方法就得同步所有实现，否则容器启动就失败。小团队初期容易忽略这点，等到第三种支付接入时才发现两个旧实现漏了 void cancelSubscription()，结果线上报 BadMethodCallException。
