Laravel 6服务容器不支持构造函数中带默认值的类型提示参数自动跳过注入，必须显式绑定并手动控制依赖解析；应避免依赖“= null”幻想，改用闭包绑定、setter注入或配置驱动。
Laravel 6 的服务容器本身不原生支持构造函数中 PHP 8 之前的可选参数（如 $service = null）的自动跳过注入。它严格依据类型提示进行反射解析，遇到未绑定、不可实例化或缺少依赖的类型时会报错，而不会因为参数有默认值就跳过解析。
构造函数可选参数的常见场景
典型情况包括：
- 一个类构造函数中某参数带默认
null值，但你希望只在需要时才注入具体实现； - 同一类在不同环境下需灵活启用/禁用某依赖（如调试日志器、通知服务）；
- 第三方库类构造函数含可选原始值（如字符串、布尔值），无法靠类型提示自动解析。
正确处理方式：闭包绑定 + 手动控制解析逻辑
必须在服务提供者（如 AppServiceProvider@register()）中显式绑定，并在闭包里判断是否提供该依赖：
$this->app->bind(MyService::class, function ($app) {
// 检查配置或条件，决定是否注入 Logger
$logger = config('app.debug')
? $app->make(LoggerInterface::class)
: null;
return new MyService($logger); // 显式传入 null 或实例
});
这样既保留了可选语义，又让容器掌握完整实例化流程。
避免直接依赖“默认值跳过”幻想
以下写法无效且危险：
class MyService
{
public function __construct(LoggerInterface $logger = null) { ... }
}
因为 LoggerInterface 是接口，没有默认实现，容器看到类型提示就会尝试解析 —— 即使写了 = null，也会触发 Target [LoggerInterface] is not instantiable 错误。PHP 的默认值只对原始类型（string, int, null 等无类型提示）生效，而类型提示优先级更高。
替代方案：使用 setter 注入或配置驱动
若构造函数灵活性要求高，推荐解耦初始化逻辑：
- 把可选依赖改为 setter 方法（如
setLogger()），构造函数保持精简； - 通过配置项控制是否绑定某服务（如
bindIf()配合条件判断）； - 用策略模式封装可选行为，让容器只解析主策略，其余按需加载。
