不该在同一个进程混用 Django 和 FastAPI，因其 ASGI 生命周期假设冲突：Django 依赖同步中间件与线程局部存储，FastAPI 面向异步上下文，混用会导致中间件失效、依赖注入异常、数据库连接问题等隐性竞态。
为什么不该在同一个进程里混用 Django 和 FastAPI
直接把 Django 和 FastAPI 注册到同一个 ASGI 应用（比如用 mount 把一个塞进另一个）看似省事，实际会触发多层中间件冲突、数据库连接复用异常、静态文件路由覆盖等问题。最典型的症状是：Django 的 auth 中间件失效，或 FastAPI 的依赖注入在 Django 请求上下文中无法解析 request.state。
根本原因在于二者对 ASGI 生命周期的假设不同：Django 仍重度依赖同步中间件栈和线程局部存储（threading.local），而 FastAPI 默认面向完全异步上下文设计依赖生命周期。强行共存不是“混合”，而是制造隐性竞态。
- 不要用
Starlette.mount()把FastAPI实例挂到Django的ASGIHandler下 - 避免共享
settings.py或models.py模块——模型迁移、字段验证逻辑在两个框架中行为不一致 - 若必须共用数据库，用独立的
SQLAlchemy或原生asyncpg/aiomysql连接池，绕过 Django ORM 和 FastAPI 的Depends双重封装
用反向代理隔离 Django 与 FastAPI 进程
真实微服务架构下，Django 和 FastAPI 应作为独立进程部署，由 Nginx 或 Traefik 做路径级路由分发。例如：所有 /api/v1/ 转发给 FastAPI 服务，/admin/ 和 /static/ 留给 Django。
关键配置点：
立即学习“Python免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- Nginx 中用
location /api/匹配前缀，后端指向http://fastapi:8000；Django 服务监听http://django:8001 - 确保两者都设置
ALLOWED_HOSTS（Django）或trusted_hosts（FastAPI 的HTTPSRedirectMiddleware）允许代理头 - 共享 session？别碰。改用 Redis 存储 token，Django 写入
auth_token，FastAPI 用redis-py读取校验，避免 Cookie 域名/Secure 标志冲突
跨服务调用时如何安全传用户身份
当 Django 视图需要调用 FastAPI 提供的实时计算接口（如 /api/v1/analyze/），不能直接传 request.COOKIES 或 sessionid——FastAPI 没有 Django 的 session backend 支持。
可行方案只有两种：
- 在 Django 端生成短期 JWT（用
PyJWT），payload 包含user_id和exp，通过Authorization: Bearer <token></token>发给 FastAPI；FastAPI 用python-jose验证并解析用户 ID - 走内部网络调用时，用固定 API Key + 请求头
X-Internal-Caller: django配合 IP 白名单（Nginx 层限制fastapi只响应来自django容器的请求） - 绝对不要在 URL 查询参数里传用户标识——日志、代理缓存、CDN 都可能泄露
数据库事务边界必须手动切开
哪怕两个服务共用同一套 PostgreSQL，也不能指望跨服务调用自动延续事务。例如 Django 创建订单后调用 FastAPI 扣减库存，若 FastAPI 失败，Django 的 transaction.atomic 不会回滚。
正确做法是引入最终一致性：
- Django 在创建订单后，向消息队列（如 RabbitMQ 或 Redis Stream）发一条
order_created事件 - FastAPI 启动一个独立消费者进程监听该事件，执行库存扣减；失败则重试或告警
- 避免在 FastAPI 接口里同步调用 Django 的
manage.py命令——进程锁、信号处理、环境变量加载都会出问题
真正难的不是怎么写代码，是怎么说服团队接受「Django 负责状态管理，FastAPI 负责无状态计算」这个职责切分。一旦开始共享模型或事务，后续拆分成本会指数级上升。
