Laravel中间件多租户怎么应用_Laravel多租户中间件的应用教程【教程】-Laravel-PHP中文网

在Laravel多租户中，中间件需优先从请求上下文（子域名/路径/Header）提取租户标识，查库后调用$tenant->makeCurrent()绑定，并加异常兜底；必须置于$middlewareGroups['web']最前以确保Session、模型查询等均生效租户上下文。

laravel中间件多租户怎么应用_laravel多租户中间件的应用教程【教程】

Laravel 多租户场景下，中间件是识别和绑定租户的最常用入口。关键不是“写个中间件”，而是确保在 handle() 执行时，租户信息已可靠加载，且能被后续所有逻辑（如模型查询、配置读取）感知。

常见错误是直接在中间件里查数据库又没缓存，或依赖路由参数但没校验是否存在——比如租户子域名 tenant1.example.com 对应的 tenant1 在数据库里已被删除，此时中间件不该静默跳过，而应明确拒绝请求。

优先从请求上下文提取租户标识：子域名用 $request->getHost() 解析，路径前缀用 $request->segment(1)，Header 用 $request->header('X-Tenant-ID')
用 Tenant::find($id) 查库后，立刻调用 $tenant->makeCurrent()（假设你用的是 stancl/tenancy 或类似包），否则 Eloquent 查询仍走主库
务必加异常兜底：if (! $tenant) { throw new NotFoundHttpException(); }，别让空租户流到控制器

租户中间件必须在 StartSession、ShareErrorsFromSession 和绝大多数业务中间件之前执行。否则 Session 数据、验证错误、甚至日志记录都可能写进默认租户的上下文。

典型现象：登录后跳转首页，用户数据正确，但日志里显示操作的是 tenant_default；或者 Nova 后台里看到的资源全是主库数据。

在 app/Http/Kernel.php 的 $middlewareGroups['web'] 中，把租户中间件（例如 InitializeTenancyByDomain::class）移到最前面
避免在 $middleware 全局数组里注册租户中间件——它只对 API 路由生效，而多租户通常依赖 Web 路由的 session 和 cookie
如果用了 SubdomainTenant 模式，确认 APP_URL 配置不含子域名，否则 Laravel URL 生成器会出错

中间件设好了租户，但 User::all() 还是查出所有租户的用户——说明模型没启用租户作用域。这不是中间件的问题，而是模型层缺失约束。

Laravel Cloud

Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。

下载

根本原因：Laravel 默认不强制租户隔离，必须显式声明。哪怕中间件已切换连接，Eloquent 若没加 whereTenantId() 或没监听 building 事件，照样全量查。

在模型里用 protected $tenantColumns = ['tenant_id'];（tenancy 包支持）或手动加全局作用域：static::addGlobalScope(new TenantScope);
检查迁移是否为每张表加了 tenant_id 字段，并设了索引：$table->unsignedBigInteger('tenant_id')->index();
注意软删除模型：若租户数据需独立回收，deleted_at 字段也得配合租户过滤，否则 withTrashed() 可能跨租户泄露

Web 请求靠中间件自动初始化租户，但 php artisan schedule:run 或队列任务（如 SendWelcomeEmail）启动时没有 HTTP 上下文，tenant()->current() 会返回 null，导致写入错误库或发错通知。

最容易被忽略的一点：队列任务序列化时不会自动捕获当前租户 ID，反序列化后执行就丢了上下文。

命令行中手动指定租户：php artisan tenant:artisan "tinker" --tenant=acme（tenancy 包提供）
队列任务构造时显式传入 $this->tenantId = $tenant->id;，handle() 里再调用 Tenant::find($this->tenantId)->makeCurrent()
避免在 AppServiceProvider::boot() 里做任何依赖当前租户的绑定（如 bind(UserRepository::class, ...)），因为 CLI 和队列不走这个流程

租户隔离真正的复杂点不在中间件写法，而在「上下文传递的完整性」——HTTP 请求、命令行、队列、甚至 Telescope 日志采集，每个入口都要单独确认租户是否真正生效。漏掉任意一个，数据就可能串租户。