必须写DatabaseRouter类并注册到DATABASE_ROUTERS，否则所有查询只走default；需实现db_for_read、db_for_write、allow_relation、allow_migrate四个方法，返回值须精确匹配DATABASES中键名，事务内读应返回None或复用当前库，避免从库不一致。
必须写 DatabaseRouter 类并注册到 DATABASE_ROUTERS，否则所有查询永远只走 default；光在 DATABASES 里加一堆从库配置，Django 完全不会自动分流。
为什么 DATABASES 配好了却没读写分离？
常见错误是只改了 DATABASES 字典，漏掉 DATABASE_ROUTERS 注册。Django 不识别 “主/从” 语义，'replica1' 和 'analytics' 在它眼里地位完全平等，路由逻辑全靠你手动控制。
-
DATABASE_ROUTERS必须是字符串路径列表，比如['myapp.routers.ReplicaRouter']，不能写成类实例或不带引号 - 模块路径要能 import：确保
myapp/routers.py存在，且ReplicaRouter是顶层类 - 启动 Django 时不会报错，但路由不生效——最典型表现是
db_for_read里的print()完全不触发
DatabaseRouter 必须实现哪四个方法？
缺一不可，少一个就抛 AttributeError。实际项目中最容易漏的是 allow_relation 和 allow_migrate，导致迁移失败或外键关联异常。
-
db_for_read()：返回从库别名（如'replica1'）或None（fallback 到default） -
db_for_write()：几乎总是返回'default'，不能轮询或随机 -
allow_relation()：跨库外键不被 Django 支持，只要obj1._state.db != obj2._state.db就该返回False -
allow_migrate()：必须显式禁止从库执行迁移，否则python manage.py migrate会在只读库上尝试 DDL，直接报OperationalError: cannot execute INSERT in a read-only transaction
db_for_read 怎么避免事务内读从库导致数据不一致？
事务中读操作如果打到从库，可能看到旧数据——因为主从同步有延迟。这不是 bug，是架构取舍，但得由你主动控制。
- 不要无脑返回
'replica1'，先检查是否在事务中：from django.db import transaction，然后用transaction.get_connection().in_atomic_block - 更稳妥的做法是判断
hints.get('using')是否已存在，有则复用，避免跨库 - 强一致性读场景（如刚提交订单立刻查状态），应主动
.using('default')，而不是依赖重试或降级逻辑 -
select_related在从库 QuerySet 上会失效：关联表默认仍走default，不是因为路由没生效，而是 Django 不支持跨库 JOIN
ConnectionDoesNotExist 错误怎么快速定位？
这个错误表面是“连不上数据库”，实际 90% 是路由返回了不存在的别名，比如写了 'slaver' 但 DATABASES 里只有 'replica1'。
- 检查
db_for_read和db_for_write的返回值是否精确匹配DATABASES字典的 key —— 区分大小写，不能多空格 - 别依赖环境变量动态生成别名键名，Django 要求所有别名在启动时就静态存在
- MySQL 主从的
NAME必须一致，否则同步失效；PORT通常不同（主库 3306，从库 8306 或 3307） - SQLite 不适合验证读写分离逻辑，
db.sqlite3和db_slave.sqlite3无法真正同步，仅限本地开发临时测试
最易被忽略的一点：Django Admin 默认全部走 default，哪怕你配好了完整路由。需要在每个 ModelAdmin 里重写 get_queryset() 并显式调 .using('replica')，否则后台页面的查询压力全压在主库上。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
