ThinkPHP全局查询范围_ThinkPHP模型全局作用域说明【解答】

ThinkPHP全局查询范围：不是“可选优化”，而是数据安全的强制过滤层

在ThinkPHP的模型世界里，有一个功能常常被误解为“高级优化项”，实则不然。它会在每一次查询、更新甚至删除操作前自动生效，默默追加WHERE条件，且无法被常规手段绕过。这就是全局作用域（baseScope），它本质上是数据访问安全的基石，而非锦上添花的装饰。

全局作用域怎么定义才生效？

想让全局作用域真正起作用，必须严格遵守框架的“契约”。关键在于，必须在模型类中定义一个名为baseScope的静态方法，并且这个方法要接收一个$query参数，最后将它返回。

• 正确姿势：public static function baseScope($query) { return $query->where('delete_time', null); }
• 常见坑点1：写成public function baseScope($query)。漏了static关键字？抱歉，框架根本不会触发它。
• 常见坑点2：写成public static function scopeBase($query)。名字不对，框架只认baseScope这个特定名称。

还有一点值得注意：如果你的模型继承自某个自定义的基类（比如BaseModel），那么baseScope方法必须定义在这个基类里。子模型并不会自动继承这个方法的定义逻辑。

当全局作用域遇上软删除：withTrashed()失灵了？

我们常用withTrashed()来临时查看包括软删除在内的所有数据。但它的工作原理你可能需要了解：它本质上只尝试移除baseScope中显式编写的、字段名匹配的软删除条件（比如delete_time IS NULL）。

问题来了：如果baseScope里除了软删除，还混入了其他业务逻辑呢？

• withTrashed()的核心是调用$query->removeWhere('delete_time')，它只认字段名。
• 假设你在baseScope里写的是where('deleted_at', null)，但模型实际的软删除字段是delete_time，那么withTrashed()将完全无效。
• 更复杂的情况是多个全局作用域叠加（例如“租户隔离”+“软删除”）。withTrashed()通常只影响第一个被注册的作用域，后面的那些过滤条件依然坚挺。

所以，一个务实的建议是：对于软删除，尽量使用框架内置的SoftDelete trait，避免在baseScope中手动处理，这样可以减少很多意想不到的冲突。

多租户场景：如何用全局作用域筑牢数据隔离墙？

在多租户系统中，数据隔离是命脉。全局作用域是实现隔离的利器，但用不好就是漏洞。核心原则是：租户ID必须在请求生命周期的极早期就确定下来，并且确保baseScope能稳定、可靠地读取到它。

• 存储位置是关键：租户标识应该存入像容器（例如think\facade\App::instance()->tenant_id）这样的可靠位置，而不是$_SESSION或全局变量里，后者在复杂流程中可能不可靠。
• 警惕循环依赖：在baseScope方法内部，要避免调用request()、session()这类Facade。它们可能触发中间件或额外的初始化流程，一不小心就会引发循环依赖错误。
• 关联模型是个盲区：这一点容易被忽略——关联模型默认不会继承主模型的全局作用域。当你执行User::with('orders')->find(1)时，Order模型必须自己定义baseScope来实现租户过滤，否则就可能泄露跨租户数据。
• 如何“开个后门”：如果真有像“系统配置表”这样需要排除租户过滤的模型，可以使用withoutGlobalScope()方法。但务必明确指定要移除的作用域类名，直接传个空数组进去是没用的。

话说回来，真正的挑战往往不在于如何写出一个baseScope方法。难的是，一旦启用它，它就深度耦合进了整个ORM的生命周期。无论是count()统计、update()更新，还是destroy()删除，都会受到它的约束。更“隐蔽”的是，在调试时查看SQL日志，你通常看不到这个条件是如何被自动加进去的，这要求开发者对其行为有深刻的理解。

立即学习“PHP免费学习笔记（深入）”；