Laravel自定义验证规则需避免构造函数依赖注入，应通过__invoke、Validator::extend或Rule::using(resolve(MyRule::class))实现服务容器集成，并注意接口绑定与运行时延迟执行。
自定义验证规则里怎么用 Laravel 的服务容器？
不能直接在 Rule 类构造函数里写依赖，Laravel 验证器不负责解析规则实例——它只调用 passes() 方法，且默认用 new static 实例化规则。所以手动 new 出来的规则对象，DI 容器根本没机会介入。
正确做法是让规则类实现 __invoke，并配合 Validator::extend 或闭包注册方式，把服务从容器里取出来再传进去：
- 用
app(ServiceClass::class)或resolve(ServiceClass::class)在规则执行时取服务 - 不要在构造函数里声明依赖，否则
php artisan optimize:clear后可能报Target [Interface] is not instantiable - 如果规则需复用且依赖较多，建议封装成独立服务类，验证逻辑只调它的方法，而非把服务塞进规则本身
Laravel 10+ 中 Rule::using() 怎么传参又保持 DI？
Rule::using() 是静态工厂方法，它内部会通过容器解析规则类，但前提是这个类必须被容器“知道”——也就是得绑定到容器或自动解析支持（比如有默认构造参数、或已通过 bind 注册）。
常见翻车点：
- 规则类没加
public function __construct(YourService $service)，却指望Rule::using()自动注入 → 不生效 - 服务接口没绑定具体实现，例如只写了
interface CacheService，但没在AppServiceProvider的register()里$this->app->bind(CacheService::class, RedisCacheService::class)→ 报Target [CacheService] is not instantiable - 规则类用了
__invoke但没声明为可调用，Rule::using(new MyRule($service))会绕过容器 → 退化成手动 new，DI 失效
在 Form Request 里用自定义规则时，如何安全访问 Auth 或 DB？
Form Request 的 rules() 方法运行时机早于中间件，Auth::user() 可能为 null；同时 Eloquent 查询若放在 rules() 返回数组里，会每次验证都执行（包括失败重试），造成 N+1 或权限绕过。
稳妥做法是把动态逻辑移到规则内部，用 closure 或可调用类延迟执行：
- 用
function ($attribute, $value, $fail) { ... }闭包，在真正校验时才查数据库或读用户 - 若需复用，写个
class UniqueForUser implements Invokable，在__invoke里用auth()->user()和DB::table(...) - 避免在
rules()数组里直接写'email' => ['required', Rule::exists('users')->where('tenant_id', tenant()->id)]——tenant()可能未初始化，且where()是链式调用，不是实时求值
为什么有时候 resolve(MyRule::class) 成功，Rule::using(MyRule::class) 却失败？
因为 Rule::using() 底层调的是 Container::make()，而 resolve() 是 Container::makeWith([]) 的快捷方式；但关键差异在于：当规则类有非可选构造参数时，Rule::using(MyRule::class) 会尝试无参构造，失败就抛异常；而 resolve(MyRule::class) 会走完整解析流程，尝试注入所有依赖。
所以实际要这么用：
- ✅
Rule::using(resolve(MyRule::class))—— 先让容器造好实例，再喂给 Rule - ✅
Rule::using(fn ($a, $b) => new MyRule($a, $b))—— 手动控制参数，适合带运行时变量的场景 - ❌
Rule::using(MyRule::class)—— 除非该类构造函数所有参数都有默认值或类型提示可被容器解析
最易忽略的一点：规则类的构造函数参数类型提示必须是容器能解析的（具体类或已绑定的接口），不能是 string、int 这类标量，否则容器直接放弃注入，报错信息还很模糊，容易卡在“为什么依赖没进来”。
