django-tenants数据库后端必须设为django_tenants.postgresql_backend，租户模型需继承TenantMixin并设auto_create_schema=True，中间件默认支持子域名识别租户，迁移需区分--shared和--tenant参数。
django-tenants 是当前 Django 生态中基于 PostgreSQL schema 实现多租户最稳定、文档最全的方案。它不依赖额外服务或复杂中间件链，核心就是「一个租户一个 schema」，所有隔离逻辑由数据库层和 ORM 层协同完成——只要你的数据库是 PostgreSQL，且项目结构允许按 schema 切分，就能快速落地。
怎么配置 django-tenants 的数据库后端？
必须替换默认 PostgreSQL 后端，否则 schema 切换不会生效。
-
ENGINE必须设为django_tenants.postgresql_backend，不是django.db.backends.postgresql - 公共 schema（
public）必须存在，且只放共享表（如Tenant模型、用户认证表等） - 租户 schema 名称不能含大写字母、特殊符号或以数字开头；推荐用小写 ASCII 字符 + 下划线
- 如果用
psycopg3（2026 年主流），需确认django-tenants版本 ≥ 4.0.0，否则会报AttributeError: module 'psycopg' has no attribute 'extensions'
示例 settings.py 片段：
DATABASES = {
'default': {
'ENGINE': 'django_tenants.postgresql_backend',
'NAME': 'saas_db',
'USER': 'postgres',
'PASSWORD': 'xxx',
'HOST': 'localhost',
'PORT': '5432',
}
}租户模型怎么定义？为什么 auto_create_schema=True 很关键？
租户模型必须继承 TenantMixin，且字段名必须含 schema_name（字符串类型）。
立即学习“Python免费学习笔记（深入）”；
-
schema_name是数据库层面的唯一标识，也是 URL 路由/域名匹配的依据 -
auto_create_schema=True表示调用.save()时自动执行CREATE SCHEMA，否则得手动运行./manage.py migrate_schemas --shared和./manage.py migrate_schemas --tenant - 若租户注册流程需要异步创建 schema（比如防爆破），可设为
False，再在后台任务中显式调用tenant.create_schema() -
domain_url字段不是必须的，但如果你用子域名路由（如acme.example.com），就必须有且唯一
最小可行模型：
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
from django_tenants.models import TenantMixin <p>class Client(TenantMixin): name = models.CharField(max_length=100) paid_until = models.DateField(null=True) on_trial = models.BooleanField(default=True) created_on = models.DateField(auto_now_add=True)</p><pre class='brush:python;toolbar:false;'>auto_create_schema = True # ⚠️ 不加这行，租户数据进不了自己的 schema</pre>
中间件怎么识别租户？域名 vs 路径路由的区别在哪？
默认中间件 django_tenants.middleware.main.TenantMainMiddleware 只支持子域名识别（tenant.example.com）。如果用路径（example.com/tenant1/）或 header 识别，必须自定义中间件并重写 get_tenant 方法。
- 子域名方式：简单、符合 SaaS 直觉，但需 DNS 配置支持通配符（
*.example.com） - 路径方式：前端无需改 DNS，但所有 URL 前缀要统一，且静态文件、管理后台路径容易冲突
- header 方式（如
X-Tenant-ID）：适合内部 API 或微前端场景，但无法用于浏览器直连 - 无论哪种方式，都必须确保
request.tenant在进入视图前已赋值，否则 ORM 查询会落到publicschema
路径路由示例（需替换中间件）：
class PathTenantMiddleware:
def __init__(self, get_response):
self.get_response = get_response
<pre class='brush:python;toolbar:false;'>def __call__(self, request):
path_parts = request.path.strip('/').split('/')
if len(path_parts) > 0:
schema_name = path_parts[0]
try:
request.tenant = Client.objects.get(schema_name=schema_name)
except Client.DoesNotExist:
pass
return self.get_response(request)</pre>迁移命令为什么分 --shared 和 --tenant？
因为 public schema 和租户 schema 的表结构完全独立：共享表（如 Client）只在 public 里建一次；租户专属表（如 Invoice、Project）要在每个租户 schema 里各建一套。
-
./manage.py migrate_schemas --shared：只作用于publicschema，用于更新租户模型、权限表等 -
./manage.py migrate_schemas --tenant：遍历所有已激活租户，对每个 schema 单独执行迁移 -
./manage.py migrate_schemas（无参数）：等价于同时跑上面两个命令，生产环境慎用，避免租户间迁移顺序错乱 - 新租户创建后，必须立即执行
migrate_schemas --tenant --schema=xxx，否则其 schema 是空的
容易忽略的点：Django 的 makemigrations 仍照常运行，但生成的迁移文件会被 django-tenants 自动打上 shared 或 tenant 标签，你不用手动区分。
schema 切换发生在连接建立后、SQL 执行前，整个过程对 ORM 透明；但一旦你手写原生 SQL 或使用 connection.cursor()，就得自己拼 SET search_path TO xxx, public ——这是最容易出错的地方。
