Laravel 5.5 本身不内置多租户支持，但可通过共享数据库+tenant_id字段+全局作用域实现可靠隔离；关键在于规避Auth::user()未就绪、tenant_id漏填、全局作用域失效三类陷阱。
直接说结论：Laravel 5.5 本身不内置多租户支持，但完全能通过「共享数据库 + tenant_id 字段 + 全局作用域」实现可靠隔离，无需升级或换包；关键不是版本限制，而是你是否绕开了 Auth::user() 在中间件执行前不可用、tenant_id 漏填、全局作用域未生效这三类高频陷阱。
tenant_id 字段怎么加才不会漏数据
不是所有表都要加 tenant_id，只加业务表（posts、orders、products），系统表（users、roles、permissions）按需处理——比如 users 表必须加，否则无法关联租户；但 password_resets 这类临时表就不需要。
- 迁移里用
$table->foreignId('tenant_id')->constrained()->cascadeOnDelete()，比unsignedBigInteger更安全，外键约束能防误删租户后残留脏数据 -
tenant_id必须设为nullable（尤其对超级管理员用户），否则注册租户前的初始用户创建会失败 - 别依赖模型事件自动填充——Laravel 5.5 的
creating事件在事务回滚时不会触发 rollback，要用saved或显式赋值
全局作用域为什么查不到数据
全局作用域失效最常见的原因是：没在 boot() 里调用 static::addGlobalScope()，或者作用域里用了 Auth::user() 但当前请求还没经过认证中间件（比如 API 路由没加 auth:api）。
- 正确写法是先检查
Tenant::current()是否存在，而不是硬绑Auth::user()->tenant_id，因为 CLI 命令、队列任务、Webhook 回调都可能没有用户上下文 - 作用域里用
whereNotNull('tenant_id')替代where('tenant_id', ...)，避免超级管理员看到空 tenant_id 的记录 - 记得在模型里禁用作用域的场景（如后台租户管理页）：用
withoutGlobalScopes()或临时移除BelongsToTenantTrait
中间件里怎么安全识别租户
Laravel 5.5 不支持 Octane，所以别用内存缓存租户对象；子域名识别（tenant1.app.com）比路径识别（/tenant1/dashboard）更稳定，但必须在 AppServiceProvider 的 boot() 里提前解析，不能等到路由匹配后。
- 解析逻辑放在
Kernel.php的$middleware最前面，确保所有后续中间件和控制器都能读到tenant_id - 用
request()->getHost()提取子域名，再查Tenant::where('slug', $subdomain)->first()，别用正则硬匹配，防止 DNS 劫持伪造子域 - 识别失败时直接
abort(404)，不要 fallback 到默认租户——这会导致数据越界
spatie/laravel-permission 怎么配合租户用
5.5 版本的 spatie/laravel-permission 默认不支持团队（teams），但可以通过手动修改配置启用基础租户权限隔离：把 config/permission.php 里的 'teams' => true 设为 true，然后运行 php artisan vendor:publish --tag=laravel-permission-config。
- 权限表（
permissions、roles）不需要加tenant_id，但关联表（role_has_permissions、model_has_roles）必须扩展字段，比如在model_has_roles加tenant_id并建复合索引 - 检查权限时用
$user->hasPermissionTo('edit-post', $tenant)，而不是$user->can('edit-post')，后者会忽略租户上下文 - 别在 Blade 模板里用
@can直接判断，先用@if (auth()->user()->currentTenant)确保租户已加载，否则 Gate 会静默失败
真正难的不是写代码，是每次部署前确认三件事：tenant_id 是否在所有 INSERT 语句里被显式设置、全局作用域是否对 Queue Worker 生效、权限检查是否绕过了租户上下文——这些点一漏，数据就混了，而且很难被测试覆盖到。
