Django、测试与部署

旧笔记包含 Django 2.2 博客项目、Selenium、Locust、JMeter 和 uWSGI 部署实验。这些资料中的具体页面、依赖版本和系统命令已经过时，本篇只保留仍适用的结构与边界。

Django 请求链路

• Project 保存全局 Settings、URL 和部署入口；App 表达可复用业务能力。
• Model 变更通过 Migration 演进，不直接依靠手工改表。
• View 负责 HTTP 适配，不应承载全部领域逻辑。
• 静态文件由构建/收集流程交给 Web Server 或对象存储，用户上传文件需要独立的权限和存储策略。
• 自定义 User Model 应在首次迁移前确定；中途替换的迁移成本很高。

旧笔记基于 Django 2.2，不能直接作为新项目依赖和配置基线。新项目应选择受支持版本，并按对应文档处理异步视图、Middleware、CSRF、认证与数据库兼容性。

Session、Cookie 与 CSRF

• Cookie 存在客户端，Session 通常只把标识放在 Cookie，状态保存在服务端或签名数据中。
• Redis Session 需要设置过期时间、序列化、安全前缀和故障策略。
• CSRF 防护验证浏览器携带的状态变更请求来自可信页面；不能为解决 403 就全局关闭 CSRF。
• HttpOnly、Secure、SameSite 与 HTTPS 共同影响 Cookie 安全。
• 登录接口还需要限流、密码哈希、会话轮换和审计，不能只验证用户名密码后写 Cookie。

自动化测试分层

层次	工具	适合验证
单元测试	unittest、pytest	函数、类和领域规则
Django 集成测试	Django Test Client、pytest-django	URL、View、ORM、认证和事务
浏览器测试	Selenium	JavaScript、浏览器交互和完整用户路径
性能测试	Locust、JMeter	并发、吞吐、延迟和容量拐点

Selenium 驱动与浏览器版本需要匹配；现代 Selenium 可以通过 Selenium Manager 管理驱动，不应默认沿用手工下载并写死本地路径的步骤。

Locust 任务描述的是虚拟用户行为。性能测试必须定义数据准备、Ramp-up、Think Time、成功条件、服务端指标和测试后清理，不能只看客户端请求数。

WSGI 与 ASGI

接口	模型	常见用途
WSGI	同步请求调用	传统 Django，同步业务与成熟部署栈
ASGI	支持异步、长连接和多协议	Async View、WebSocket、异步 IO

uWSGI 是 WSGI Server/应用容器之一，不是 Python Web 部署的唯一方案。现代部署还可选择 Gunicorn、Uvicorn、Daphne 等，具体取决于 WSGI/ASGI、并发模型和框架支持。

生产部署需要处理：

• 反向代理传递的 Host、Scheme 和客户端地址可信边界。
• Worker 数量、超时、优雅关闭和最大请求数。
• 静态文件、上传文件和应用进程分离。
• 数据库连接数与 Worker/线程/协程数量联动。
• Migration 的发布顺序和向前/向后兼容。
• 健康检查、结构化日志、指标、Tracing 和错误聚合。

旧笔记中的 CentOS 防火墙关闭、SELinux 关闭、固定 IP、源码安装 Nginx 等命令不迁入知识正文；这些做法既环境相关，也可能削弱安全性。