结论是django本身不处理并发，真正扛住高并发的是uwsgi的进程/线程模型加nginx的反向代理与静态资源卸载；生产环境必须用socket（unix或tcp）配合nginx的uwsgi_pass，禁用裸http模式，配好processes、threads、max-requests、vacuum及uwsgi_params，同时关闭debug、正确配置static_root和数据库连接复用。
直接说结论：Django 本身不处理并发，真正扛住高并发的是 uWSGI 的进程/线程模型 + Nginx 的反向代理与静态资源卸载，不是改 Django 代码。
uWSGI 启动参数怎么配才真正起效
很多人写 uwsgi --http :8000 --module mysite.wsgi 能跑通就以为完事了，但生产环境这根本扛不住并发。关键在于用 socket + 进程模型，而不是裸 http 暴露端口。
-
socket必须用 Unix domain socket（如/tmp/mysite.sock）或 TCP（如127.0.0.1:8001），Nginx 通过uwsgi_pass转发请求；http参数只适合调试，它绕过 Nginx，且无法复用连接、无 SSL 终止能力 -
processes和threads要按 CPU 核心数权衡：4 核机器设processes = 4+threads = 2比processes = 8+threads = 1更稳；Python 的 GIL 让纯 CPU 密集型任务难靠多线程提升，但 I/O 等待多的 Web 请求能受益 -
max-requests和vacuum必须开：max-requests = 5000防内存泄漏累积，vacuum = true确保子进程退出后释放资源，否则长连接下内存会缓慢上涨
为什么 Nginx 不配 uwsgi_param 就会 502
uWSGI 不是 HTTP 服务器，它收的是 uwsgi 协议二进制包。Nginx 默认发 HTTP 包过去，uWSGI 解不开，直接拒收——表现就是 502 Bad Gateway。
python-docx Skill功能概述python-docx Skill是一项面向实际任务的技能，主要用于本Skill提供使用python-docx生成专业Word文档的标准方法和最佳实践；生成安全服务方案文档；核心要点生成技术架构设计文档；生成任何需要专业排版的Word文档；核心库 : python-docx；使用与执行辅助库 : docx.shared , docx.enum , docx.oxml.ns；标准代码模板；1. 文档初始化；2. 字体设置（必须！它将相关步骤、工具调用和结果整理方式集
- 必须在 Nginx server 块里显式加
include uwsgi_params;（路径通常是/etc/nginx/uwsgi_params），它定义了一组uwsgi_param，把 HTTP 头转成 uwsgi 变量，比如REQUEST_METHOD、PATH_INFO - 别手写
uwsgi_param，容易漏掉UWSGI_SCRIPT或UWSGI_PYHOME（如果用了虚拟环境）；更别用proxy_pass代替uwsgi_pass，那是给 HTTP 后端用的 - 检查 uWSGI 日志有没有
invalid request block或bad request，基本就是协议没对上
Django settings.py 里哪些配置影响并发吞吐
不是所有设置都和并发强相关，但几个关键项配错，会让 uWSGI 白忙活。
-
DEBUG = False必须关掉，否则 Django 中间件会记录大量日志、做模板重编译，单请求耗时翻倍 -
STATIC_ROOT和collectstatic必须到位：Nginx 直接 serveSTATIC_ROOT下文件，否则每个静态请求都打到 uWSGI，白白消耗 worker 进程 -
DATABASES的CONN_MAX_AGE设为60（秒），复用数据库连接；但别设太高，PostgreSQL 连接空闲太久会被服务端 kill，反而触发重连开销 - 别在视图里做同步阻塞操作（如 requests.get()、time.sleep()），uWSGI worker 被占住就卡死；这类逻辑必须扔进 Celery 或 asyncio.run_in_executor
PyPy3 真的值得换吗
PyPy3 对 CPU 密集型计算（如数据清洗、复杂模板渲染）有明显加速，但对典型 Django 请求（ORM 查询 + JSON 序列化 + 模板渲染）收益有限，且启动慢、兼容风险高。
- uWSGI 启动 PyPy3 需要额外参数：
pypy-lib指向libpypy3-c.so，pypy-home指向 PyPy 安装根目录；漏掉任一参数，uWSGI 启动失败或报SyntaxError（因 PyPy3 的 print 语法和 CPython 不同） - PyPy3 的 JIT 在冷启动后 10–20 分钟才稳定，压测时前 1000 次请求可能比 CPython 还慢；小流量项目完全没必要折腾
- 第三方包兼容性是硬伤：带 C 扩展的包（如
psycopg2、numpy）需确认支持 PyPy3，否则直接 ImportError
最常被忽略的其实是 uWSGI 日志级别和 stats 接口——没开 stats 就像开车没仪表盘，调并发参数全靠猜；而日志设太低（如 log-level = 1）会漏掉关键错误，比如 socket 权限拒绝、chdir 失败这类启动即崩溃的问题。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
