上下文绑定用于同一接口在不同类中需不同实现的场景，须在服务提供者register()中用when()->needs()->give()链式调用配置，仅在指定类解析时生效，避免全局绑定冲突。
上下文绑定（Contextual Binding）在 Laravel 6 中用于解决“同一接口在不同类中需要不同实现”这一典型问题。它不是全局替换，而是在特定依赖场景下精准指定实现类，避免用 bind() 或 singleton() 做粗粒度覆盖带来的冲突。
什么时候必须用上下文绑定
当多个类都依赖同一个接口，但各自需要不同的具体实现时：
-
支付服务：订单系统需要
PaymentGateway接口，但SubscriptionService要用 Stripe，RefundService却要用 PayPal -
日志通道：后台任务希望写到
SyslogLogger，而 API 控制器想用JsonApiLogger，两者都依赖LoggerInterface -
缓存策略：用户会话用 Redis 缓存，但配置项读取走 File 缓存，二者都声明依赖
CacheInterface
怎么写上下文绑定（Laravel 6 写法）
必须在服务提供者的 register() 方法中完成，使用 when(...)->needs(...)->give(...) 链式调用：
// app/Providers/AppServiceProvider.php
public function register()
{
// 当 SubscriptionService 被解析时
$this->app->when(SubscriptionService::class)
->needs(PaymentGateway::class)
->give(StripeGateway::class);
// 当 RefundService 被解析时
$this->app->when(RefundService::class)
->needs(PaymentGateway::class)
->give(PayPalGateway::class);
// 也可绑定闭包，支持依赖注入
$this->app->when(ApiController::class)
->needs(LoggerInterface::class)
->give(function ($app) {
return new JsonApiLogger($app->make('config')->get('logging.channels.api'));
});
}
注意：when() 参数必须是完整类名（FQCN），needs() 是接口或抽象类，give() 可传类名、闭包或已实例化对象（不推荐后者）。
常见踩坑与验证方式
上下文绑定容易失效，关键要确认三点：
-
绑定时机：只能在
register()中注册，boot()里写会被忽略（容器已开始解析依赖） -
类路径正确性：检查是否漏了
use语句，比如写App\Services\PaymentGateway::class，但实际接口在App\Contracts\PaymentGateway -
验证是否生效：手动 make 目标类，再检查其属性是否为预期实现
$service = app()->make(SubscriptionService::class);<br>dd($service->gateway instanceof StripeGateway); // 应返回 true
和普通 bind/singleton 的本质区别
普通绑定是“接口 → 实现”的静态映射；上下文绑定是“当 A 类被创建时，它所依赖的 X 接口 → 给 Y 实现”的条件映射。它不改变全局行为，只在构造依赖图的那一刻动态干预，因此更安全、更可预测。
