django复杂系统架构核心是控节奏、分边界、留余地：模型按业务域切分并隔离关联，api与页面分离且url即契约，配置多环境拆分并零硬编码，外部集成通过接口抽象与适配器实现。
用 Django 搭建复杂 Web 系统，核心不是堆功能，而是控节奏、分边界、留余地。关键不在“怎么写”，而在“怎么拆”和“怎么连”。
模型层：按业务域切分，别按数据库表建模
Django 的 models.py 容易变成大杂烩。复杂系统里，一个 App 不该对应一张表，而应对应一个业务概念（比如 “订单中心”、“用户权限域”、“内容审核流”）。每个域内模型保持内聚，跨域关联用明确的 service 层或 domain event 处理，避免 ForeignKey 横跨多个业务边界。
- 把强一致性逻辑（如库存扣减+订单生成）放进 model 的
save()或自定义 manager 方法，但仅限原子操作 - 弱一致性或耗时操作（如发通知、更新搜索索引）扔给 Celery 或异步 signal handler
- 敏感字段（密码、token、手机号）统一用
EncryptedCharField或数据库级加密，别靠注释提醒自己“这里要加密”
视图与路由：API 和页面分离，URL 即契约
别让 views.py 同时服务 HTML 渲染和 JSON 接口。复杂系统必须区分：views/（面向用户页面，用 Class-Based View + TemplateResponse），api/v1/（纯 REST，用 DRF 的 APIView 或 ViewSet）。URL 路径体现资源语义，比如 /api/v1/orders/{id}/cancel/ 比 /cancel_order/?order_id=123 更可维护。
- 所有 API 接口加版本前缀（
v1），为后续兼容留退路 - 用
django.urls.path替代正则url()，提高可读性；参数类型强制声明，如path('items/<pk>/', ...)</pk> - 登录态、权限校验统一走 middleware 或 DRF 的
permission_classes，别在每个 view 里重复写if not request.user.is_authenticated:
配置与环境：一份代码，多套配置，零硬编码
settings.py 不是配置终点，而是入口。复杂系统必须拆出 settings/base.py（通用）、settings/dev.py（本地调试）、settings/prod.py（生产），用 python manage.py runserver --settings=myapp.settings.dev 切换。密钥、数据库地址、第三方 API key 全部从环境变量读取，用 os.getenv('DB_URL', 'sqlite:///db.sqlite3')，绝不在代码里写死。
立即学习“Python免费学习笔记（深入）”；
- 用
django-environ解析 .env 文件，支持不同环境差异化加载（比如 dev 开启 debug toolbar，prod 关闭） - 静态资源路径、媒体文件存储（S3 / 阿里云 OSS）也通过配置驱动，避免上线后改代码再部署
- 数据库迁移脚本（
migrations/）每次提交前手动检查生成内容，禁止出现RunPython带业务逻辑的迁移——那是数据脚本的事
扩展与集成：接口先行，适配器兜底
复杂系统迟早要对接支付、IM、BI、短信平台。不要在业务逻辑里直接调用 requests.post(xxx)。抽象出 interface（如 PaymentGateway），提供标准方法（charge(), refund()），再为微信、支付宝各写一个 adapter。这样换渠道只需新增类，不碰主流程。
- 外部调用一律设超时（
timeout=(3, 10)）、重试（最多 2 次）、降级返回（如支付失败时返回“稍后重试”，而非 500） - 所有第三方回调（如微信支付通知）单独开 endpoint，做签名验证 + 幂等处理（用唯一 transaction_id 做数据库去重）
- 日志中记录关键外部交互（请求头、响应体摘要、耗时），但自动过滤敏感字段（卡号、身份证号），用自定义 log filter 实现
基本上就这些。Django 的优势不是它多灵活，而是它把“不该自由发挥”的地方都框住了。架构的关键，是尊重它的约束，再在约束里找伸缩空间。
