PHP分布式任务框架需业务层补全多租户与权限控制，因任务执行无HTTP上下文，必须显式注入tenant_id和userId；Horizon需按租户隔离进程、日志、Redis前缀及失败表，并强化重试上下文固化。
PHP分布式任务框架（如 Laravel Horizon、Supervisor + Redis 队列、或自研基于 Beanstalkd/RabbitMQ 的调度器）本身不内置多租户与细粒度权限控制，必须由业务层补全。直接复用框架默认的 Web 权限模型（如中间件鉴权）在任务上下文中会失效——因为任务执行时无 HTTP 请求、无 Session、无当前用户上下文。
任务执行时如何获取租户 ID 和用户权限
任务队列中无法自动携带运行时身份信息，必须显式注入。否则 tenant_id 丢失会导致数据写错库、日志混淆、权限绕过。
- 所有可被异步触发的任务类（如
SendNotificationJob）构造函数或handle()方法参数中，必须显式接收$tenantId和/或$userId，而非从Auth::user()或全局上下文读取 - 投递任务时，由发起方（如控制器）主动传入：
dispatch(new ProcessOrderJob($order->id, $tenantId, $userId));
- 若使用 Laravel，可借助
JobMiddleware在任务执行前还原租户上下文：classTenantContextMiddleware implements ShouldQueue{ publicfunctionhandle($job, $next) { TenantContext::set($job->tenantId); $next($job); } }并在任务类中声明：public $middleware = [TenantContextMiddleware::class];
- 切勿依赖
session_start()或$_SESSION—— CLI 环境下无效，且多进程间不共享
Laravel Horizon 的租户隔离配置陷阱
Horizon 默认按「环境名」（HORIZON_ENV）分组监控任务，但该配置与租户无关。若多个租户共用一个 Horizon 实例，所有任务混在一起，既无法按租户统计耗时，也无法限制单租户并发数。
- 必须重写
Horizon::routeScheduling()或自定义Supervisor配置，为每个租户启动独立的 Horizon 进程（通过HORIZON_ENV=tenant_123区分），否则maxProcesses是全局生效的 - Dashboard 访问需加租户白名单：Horizon 路由默认开放，应通过中间件校验请求头
X-Tenant-ID或 JWT 中的tid字段，拒绝非授权租户访问 - Redis key 命名空间未自动隔离：Horizon 使用固定前缀
horizon:，多个租户共用同一 Redis DB 时会产生冲突。需在config/horizon.php中动态设置：'prefix' => 'horizon:' . (TenantContext::get() ?? 'shared'),
任务日志与审计必须绑定租户上下文
异步任务产生的日志（如 Log::info()、数据库操作日志、失败重试记录）若不含 tenant_id，排查问题时根本无法定位是哪个租户的数据异常。
立即学习“PHP免费学习笔记（深入）”；
- 所有日志通道（尤其是
daily或stack）应启用context注入，在config/logging.php中配置：'tap' => [AddTenantContext::class],
并在AddTenantContext中自动附加['tenant_id' => TenantContext::get()] - 任务失败后进入
failed_jobs表，该表必须增加tenant_id字段，并在failed()方法中手动填充，否则无法按租户筛选失败任务 - 数据库审计日志（如操作人、时间、租户）不能只靠 Eloquent
created_by，因为任务可能以系统账号运行——必须强制从任务参数中提取$tenantId和$userId写入审计字段
最易被忽略的一点：任务重试机制本身不继承原始调用者的权限上下文。一次失败后自动重试，若没固化 tenant_id 到任务序列化数据中，第二次执行可能因上下文丢失而写入错误租户数据。务必确认你的队列驱动（Redis/Database）对任务 payload 的序列化是完整且不可篡改的。
