Lara vel全局作用域：为模型查询自动穿上“统一制服”
在Lara vel应用开发中，你是否遇到过这样的场景：几乎每次查询某个模型时，都需要重复添加相同的条件？比如，只想查询状态为“启用”的用户，或者必须根据当前租户ID自动过滤数据。如果每个查询都手动加上where('status', 1)，不仅代码冗余，更容易因遗漏而出错。
这时，全局作用域（Global Scope）就该登场了。它的核心作用，就是为模型的所有查询自动、统一地“穿上”预设的条件“制服”，确保数据访问的一致性。下面，我们就来详细拆解它的几种实现方式。
一、使用闭包定义全局作用域：轻量快捷的“匿名”方案
对于逻辑简单、无需复用的条件，闭包方式是最直接的选择。它省去了创建独立类的步骤，直接在模型内部“一站式”搞定。
具体操作很简单：在目标模型的boot方法中，调用addGlobalScope方法。这个方法接收一个闭包，闭包内可以拿到$builder（查询构造器）和$model（模型实例）两个参数。接下来，就是你的表演时间了——通过$builder->where(...)来添加任何你需要的固定条件。
一个小建议：通常把这个注册逻辑放在boot方法的顶部，确保它在模型生命周期的早期就生效。
二、定义独立的作用域类：可复用、易维护的“正规军”
当你的过滤逻辑比较复杂，或者需要在多个模型之间共享时，闭包就显得力不从心了。这时，创建一个独立的作用域类才是更优雅、更符合设计原则的做法。
首先，通过Artisan命令php artisan make:scope TenantScope来生成一个作用域类。这个类需要实现Illuminate\Database\Eloquent\Scope接口，并重写其apply方法。你的核心过滤逻辑，就写在这个apply方法里。
最后，在需要应用的模型中，于boot方法内注册它：addGlobalScope(new TenantScope)。这样一来，清晰的分工、更好的可测试性就都实现了。
三、使用本地作用域替代全局作用域：按需调用的“灵活选项”
全局作用域是“强制生效”，但有时候，我们只希望条件在显式调用时才被应用。比如，一个“活跃用户”的查询条件，可能只在部分业务逻辑中使用，而不是每次查用户都要用。
这时，就该本地作用域（Local Scope）上场了。它在模型里定义一个以scope开头的方法（例如scopeActive），方法内接收$query参数并添加条件。使用时，像这样调用：User::active()->get()。
它给了开发者最大的灵活性，避免了全局作用域可能带来的“误伤”，特别适合那些非普适性的查询条件。
四、排除已注册的全局作用域：如何“临时脱掉制服”
全局作用域虽好，但总有例外。比如在后台管理界面，你可能需要查看所有数据（包括被软删除的）；或者在执行数据迁移脚本时，需要绕过租户隔离。这就需要在特定查询中，临时排除某个全局作用域。
方法很直接：使用withoutGlobalScope。对于类形式的作用域，传入类名即可：User::withoutGlobalScope(TenantScope::class)->get()。要排除多个？那就传一个数组进去。
对于用闭包注册的作用域，排除时需要一点小技巧：注册时必须给它指定一个唯一的字符串键名（例如'active'），排除时同样使用这个键名：withoutGlobalScope('active')。
五、禁用所有全局作用域：回归“原始查询”的终极手段
在极少数需要“完全原始”数据的场景下，比如全库数据导出或某些底层同步任务，你可能希望暂时屏蔽所有全局作用域，包括Lara vel框架内置的（比如软删除作用域）。
这个“大招”就是withoutGlobalScopes方法。静态调用它且不传任何参数，你将得到一个“纯净版”的查询构造器，之后的所有链式操作都不会受到任何全局作用域的干扰。
不过，务必慎用此功能。因为它真的会禁用一切，包括那些你可能依赖的核心功能。调用前，请务必确认你的业务逻辑能够处理“赤裸裸”的原始数据。
