RabbitMQ多租户隔离必须基于vhost实现，ThinkPHP6仅负责连接与发消息；需通过子域名或请求头在中间件早期绑定可信vhost，动态切换队列连接，禁用guest用户、删除默认vhost并为每个vhost配置精确权限策略。
ThinkPHP6 本身不处理 RabbitMQ 的多租户隔离，RabbitMQ 的租户边界在 vhost 层，而 ThinkPHP 只负责连接和发消息。关键不是“ThinkPHP 怎么做”，而是「如何让每个租户的请求，安全、稳定、不混淆地落到它专属的 vhost 上」。
为什么不能复用同一个 vhost + tenant_id 字段？
这是最容易踩的坑：以为只要所有队列名加租户前缀（如 queue-tenant-a-order），再靠业务代码过滤，就能替代 vhost 隔离。实际不行——
-
vhost是 RabbitMQ 的元数据隔离层，不同vhost的同名队列完全无关；而单vhost内靠命名区分，一旦消费者没校验前缀或发布者写错，消息就进错队列 - 权限模型基于
vhost粒度：你无法对 “vhost=/中以tenant-a-开头的队列” 单独授权，只能整vhost授权或按正则匹配资源名（但正则不防误操作） - 管理插件里所有监控、告警、队列清理都按
vhost维度组织，混租会丧失可观测性
ThinkPHP6 请求生命周期中如何绑定 vhost？
和数据库租户识别一样，vhost 选择必须发生在中间件早期，且必须可信、不可篡改。不能从 URL 或表单读，也不能依赖 session。
- 推荐方式：通过子域名或请求头绑定，例如
tenant-a.example.com→vhost=/tenant-a，或X-Tenant-ID: tenant-a→vhost=/tenant-a - 必须在中间件（如
app/middleware/BindRabbitVhost.php）中完成，并确保它排在app/middleware.php的最前面，早于任何服务注册、日志初始化、队列监听启动 - 把解析出的
vhost名写入请求上下文：$request->rabbitVhost = '/tenant-a'，后续所有 RabbitMQ 客户端实例（如thinkqueueconnectorAmqp子类）都从这里取值 - 禁止在模型、命令行、定时任务里动态拼
vhost—— CLI 场景没有$request，必须显式传参或通过环境变量（如APP_TENANT=tenant-a）注入
连接池与客户端实例怎么避免跨租户复用？
RabbitMQ 客户端（如 php-amqplib）通常按连接参数缓存连接实例。如果多个租户共用同一套 host/port/username/password，只改 vhost，极可能复用旧连接导致消息发到错误 vhost。
立即学习“PHP免费学习笔记（深入）”；
- 显式构造独立连接：每次发消息前，根据
$request->rabbitVhost创建新连接实例，不复用全局连接池（适合低频场景） - 更优解：为每个租户预置连接配置，在
config/queue.php中定义多个amqp连接项，例如：'connections' => ['tenant_a' => [...'vhost' => '/tenant-a'...], 'tenant_b' => [...'vhost' => '/tenant-b'...]]，然后在中间件里动态切换Queue::connection('tenant_a') - 切记：不要用
env('RABBITMQ_VHOST')这种全局配置，它无法支持运行时切换
生产环境必须关掉的默认行为
有三个默认设置不关，多租户就形同虚设：
- 禁用
guest用户：它默认有/的全权限，且密码是明文guest，极易被爆破或误用 —— 执行rabbitmqctl delete_user guest - 删除默认
vhost=/：除非真有全局管理需求，否则删掉它，避免新用户意外落到该空间 —— 执行rabbitmqctl delete_vhost / - 所有
vhost必须配权限策略：仅创建vhost不等于隔离，必须用rabbitmqctl set_permissions -p "/tenant-a" user-a "^tenant-a\..*$" "^tenant-a\..*$" "^tenant-a\..*$"限制资源名正则，禁用^.*$
真正难的不是创建十个 vhost，而是让每一条消息、每一个消费者、每一个 CLI 命令、每一个定时任务，都在正确的 vhost 上执行 —— 这要求租户上下文从请求入口开始就贯穿整个生命周期，且不能有任何环节绕过它。
