Yii 2 多租户有三路径：独立数据库（最强隔离，需重置db组件并重建连接）、共享库+独立Schema（需统一schema注入与事务规避）、共享库+行级隔离（须全局拦截所有查询路径）。选错方案重构代价极高。
Yii 2 做多租户，核心不是“能不能”，而是“选哪条路”——独立数据库、共享库+独立 Schema、共享库+共享 Schema（行级隔离），三者性能、安全、维护成本差异极大，选错一种，后期重构代价远超预期。
独立数据库方案：租户ID换DB连接，但必须重置整个 db 组件
这是最彻底的隔离方式，适合金融、医疗等强合规场景。关键不是改 dsn 字符串，而是要让 Yii 完全重建连接实例，否则事务、连接池、查询缓存都可能跨租户污染。
- 不能只写
Yii::$app->db->dsn = str_replace('{tenantId}', $tenantId, Yii::$app->db->dsn)—— 这只是改了配置，连接对象本身没变，旧连接还在用老库 - 必须调用
Yii::$app->setComponents(['db' => $newDbConfig])，再显式调用Yii::$app->db->open() - 务必在
beforeRequest事件中执行，不能放在控制器里——否则中间件、日志、RBAC 初始化都可能走错库 - 迁移脚本要单独为每个租户运行：
./yii migrate --migrationPath=@app/migrations/tenant --db=db_tenant_123
共享数据库 + 独立 Schema：用 schemaName 控制表空间，但模型必须统一入口
MySQL 的 schema 就是 database，PostgreSQL 才是真正意义上的 schema；Yii 2 对两者抽象不一致，容易踩坑。重点不在定义，而在“所有模型必须经过同一套 Schema 注入逻辑”。
- 别在每个模型里手动写
public static $tableName = 'tenant_123.user';—— 这无法动态切换，且破坏 AR 惯例 - 正确做法是在基类模型中重写
getTableSchema()，并确保Yii::$app->tenant->schemaName是线程安全的（用ThreadLocal或请求上下文） - 注意
createCommand()直接拼 SQL 时不会自动加 schema 前缀，必须显式写"SELECT * FROM {$schema}.user" - 事务跨 schema 在 MySQL 不支持，所以一个事务里不能同时操作
tenant_a.order和tenant_b.user
共享库 + 行级隔离：靠 tenant_id 字段过滤，但全局拦截器必须覆盖所有查询路径
看似最省事，实则最容易漏——只要有一处 find()->all() 没加 tenant 条件，数据就裸奔。Yii 2 没内置租户拦截，必须自己补全所有漏洞点。
-
ActiveRecord::find()要重写基类的find()方法，统一加andWhere(['tenant_id' => Yii::$app->tenant->id]) -
createCommand()必须封装成tenantCommand()工厂，禁止直接 new Command - 关联查询（
with()）默认不继承主模型的 tenant 条件，得在关系定义里显式加'on' => ['tenant_id' => new \yii\db\Expression('[[tenant_id]]')] - 软删除、统计类查询（
count()、sum()）常被忽略，必须单独检查
租户识别时机错了，后面全白搭
租户 ID 必须在应用生命周期最早期就确定，晚于 beforeRequest 就来不及影响组件初始化。常见错误是等到登录后才解析，结果 RBAC 规则、日志记录、数据库连接都已按默认租户加载。
- 推荐在
bootstrap数组里注册一个TenantBootstrap类，在bootstrap()方法中完成识别与上下文设置 - 子域名识别优先级高于请求头，但 Nginx/Apache 必须提前把
HTTP_HOST透传进 PHP，不能依赖$_SERVER['SERVER_NAME'] - 测试时用
curl -H "X-Tenant-ID: 456" http://localhost/api/user验证是否生效，比前端调试快得多 - 务必在每次请求结束时调用
TenantContext::clear()，避免 FPM 进程复用导致租户上下文残留
最难的不是写代码，是确认“所有数据出口都被堵死了”——包括日志、缓存键、导出 CSV、定时任务、WebSocket 推送，这些地方一旦漏掉 tenant 上下文，隔离就形同虚设。
