thinkphp 6 全局租户作用域需显式注册且依赖可信上下文：在基模型 boot 中调用 static::addglobalscope('tenant', new tenantscope())，tenantscope 须实现 scopeinterface 并从中间件注入的静态上下文取 tenant_id；关联查询、软删除、cli/队列场景均需专项处理。
ThinkPHP 6 的全局作用域如何自动加租户条件
全局作用域不是“自动生效”的魔法，必须显式注册到模型上，否则 where、select、update 全部绕过隔离。常见错误是只在基类里写了 boot 方法，但没调用 static::addGlobalScope()，或者用了 useGlobalScope(false) 却忘了关掉。
实操建议：
- 在基模型（如
app\model\BaseModel）的boot方法中，用static::addGlobalScope('tenant', new TenantScope())注册 -
TenantScope必须实现think\Model\ScopeInterface，apply方法里调用$builder->where('tenant_id', $tenantId)，其中$tenantId应从请求上下文（如think\Request或自定义TenantContext类）获取，不能硬编码或读取 session —— CLI 命令、队列任务会失效 - 如果某次查询确实需要跨租户（如后台管理），用
withoutGlobalScope('tenant')，而不是useGlobalScope(false)，后者会禁用所有全局作用域，风险更高
租户 ID 从哪来？不能依赖 session 或 cookie
多租户系统里，tenant_id 是数据隔离的唯一事实来源，但它绝不能来自不可信或不可控的客户端输入。常见错误是直接读 input('tenant_id') 或 session('tenant_id')，结果导致租户串查、越权访问甚至 SQL 注入（若拼进原生查询）。
实操建议：
- 推荐方案：通过子域名（如
tenant1.example.com）或请求头（如X-Tenant-ID）提取，由中间件统一解析并写入think\App或静态上下文类，模型作用域只读这个可信源 - 禁止在模型里调用
session()或cookie()—— ThinkPHP 的模型可能在命令行、定时任务、消息队列中运行，session 根本不存在 - 如果必须用 URL 参数（如 SaaS 后台），需配合白名单校验：
in_array($id, TenantService::getAllowedIds())，且该列表必须缓存，不能每次查库
软删除 + 全局作用域 = 查询结果异常
当模型启用了软删除（use SoftDelete），ThinkPHP 会自动添加 delete_time IS NULL 条件；若再叠加租户作用域，两个 WHERE 条件的执行顺序和逻辑组合容易出问题，典型现象是：明明有数据，count() 返回 0，或 find() 查不到记录。
实操建议：
- 软删除作用域和租户作用域必须共存，但不能各自独立注册 —— 否则底层 SQL 可能生成重复
AND或括号嵌套错乱。应合并为一个作用域类，apply中统一处理：$builder->where('tenant_id', $tid)->where('delete_time', null) - 避免在作用域里调用
$builder->removeWhere('delete_time')等手动干预，ThinkPHP 8+ 对软删除的底层处理已更稳定，优先信任框架机制 - 测试时务必覆盖「已软删除的租户数据」场景：插入一条
tenant_id=123且delete_time != null的记录，确认select和withTrashed()行为符合预期
关联查询（with）不走全局作用域怎么办
with('profile') 默认不会给关联模型自动加上租户条件，这是最隐蔽的越权漏洞点。表现是主模型被隔离了，但关联查出来的却是全量数据，比如用户 A 看到了用户 B 的订单详情。
实操建议：
- 关联定义里必须显式指定条件：
hasOne('Profile')->where('tenant_id', $this->tenant_id)，其中$this->tenant_id需在基模型构造或初始化时注入，不能靠闭包捕获外部变量（序列化失败） - 更可靠的方式：重写关联方法，例如
profile()内部返回$this->hasOne(Profile::class)->when($this->tenant_id, function ($q) { return $q->where('tenant_id', $this->tenant_id); }) - 慎用
withCount和withSum—— 它们底层走子查询，若子查询没继承租户条件，结果就是错的。测试时一定要比对 SQL 日志，确认子查询里含WHERE tenant_id = ?
租户隔离真正的难点不在加条件，而在确保每条 SQL 的每个分支都经过同一套可信上下文校验。漏掉一个关联、一个命令行入口、一次队列消费，整个隔离就形同虚设。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
