webman可通过协程安全上下文、可控中间件顺序和动态数据库管理实现生产级多租户；需在首个中间件基于http_host识别租户并调用tenantcontext::setcontext()，确保所有操作携带tenant_id，末尾必须用try/finally调用destroy()清理协程上下文。
Webman 本身不提供开箱即用的多租户能力，但它的协程安全上下文、中间件执行顺序可控、数据库连接可动态管理这三点，足以支撑生产级多租户系统。关键不是“有没有内置功能”，而是你能否在请求最早期就锁死 tenant_id，并确保后续所有数据操作（查询、写入、缓存、日志）都自动携带这个上下文。
租户识别必须在第一个中间件完成
识别晚了，模型构造、日志记录、缓存写入可能已发生，导致跨租户污染。不能依赖 session、URL 参数或 request()->domain() —— CLI、队列、WebSocket 场景下这些都不可用或被污染。
- 优先从
$_SERVER['HTTP_HOST']或反向代理下的$_SERVER['HTTP_X_FORWARDED_HOST']提取原始域名（如tenant1.example.com） - 查库匹配租户记录时，避免先查租户表再连库——容易形成死循环；建议用域名映射规则生成库名（如
tenant1.example.com → db_tenant1） - 识别后立刻调用
TenantContext::setContext()，把tenant_id、db_name、isolation_mode写入当前协程上下文 - 该中间件必须注册在
app/middleware.php的最顶部，且不能被其他中间件提前终止
数据库连接不能复用全局配置
Webman 默认 PDO 连接池是单例+懒加载，改 config 不会重建连接。现象是：明明设了新库名，Db::table('users')->get() 还是从旧库查。
- 独立数据库模式：在
TenantContext::setContext()后，用原生PDO新建连接，并绑定到容器特定 key（如db.tenant），所有租户内模型强制使用该连接实例 - 共享库 + 独立 Schema 模式：修改
database.php中的dbname为占位符，在模型基类getTableName()中拼接前缀：return $this->prefix . TenantContext::id() . '.' . $this->table; - 务必显式调用
Db::clearConnection('tenant')清空旧连接缓存，否则连接复用会导致错库 - 禁止用
Db::table()绕过模型——它不走模型的连接绑定逻辑，也不触发租户前缀拼接
行级隔离不能只靠 tenant_id 字段
即使表里有 tenant_id 列，User::find(1) 仍可能查出其他租户用户。Eloquent/ThinkPHP/Webman ORM 都不自动加租户条件，这是设计使然，不是 bug。
- 不要依赖“全局 scope”自动注入
WHERE tenant_id = ?——它对Db::table()、原生 SQL、withTrashed() 完全无效 - 正确做法是：所有查询必须显式带租户上下文，例如
User::where('tenant_id', TenantContext::id())->find(1) - 如果用 PHP-Casbin 做权限控制，需启用域（domain）模式：
enforcer.addPermissionForDomain('tenant_123', 'user1', 'order', 'read')，否则 RBAC 规则无法按租户隔离 - 关联查询要双重约束：主表和关联表都得加
tenant_id条件，否则with('orders')可能拉出别的租户订单
协程销毁必须手动调用 destroy()
这是线上最隐蔽的数据越界来源。Webman 基于 Workerman 协程复用机制，若不主动清理，上一个请求的 TenantContext 会残留，导致下一个请求查错库、写错表、记错日志。
- 必须在中间件末尾（不是控制器、不是模型事件）调用
TenantContext::destroy() - 不能只在成功路径调用——异常分支也要保证执行，建议用
try/finally包裹 - 测试时重点覆盖高并发场景：用 ab 或 wrk 压测，观察是否出现跨租户数据混杂
- 日志中打点验证：在中间件开头打印
TenantContext::id()，结尾再打一次，确认是否清空
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
