uWSGI多进程配置的核心参数是processes，必须搭配master=true才生效；若用http模式则多进程被禁用，应改用socket模式配合Nginx。
uWSGI多进程配置的核心参数是processes，不是workers
很多人看到文档里写 workers 就直接用，结果启动失败或被忽略——uWSGI INI 配置中真正生效的是 processes（命令行参数也叫 --processes），workers 是旧版别名，部分版本已弃用。不加 master = true 时，processes 会被静默忽略。
常见错误现象：uwsgi --ini uwsgi.ini 启动后只看到 1 个 worker 进程，ps aux | grep uwsgi 查不到预期数量。
-
processes = 4表示创建 4 个子工作进程（每个独立 Python 解释器） - 必须搭配
master = true，否则 uWSGI 不启用主进程管理逻辑，processes不生效 - 若用
--http模式（如--http :8000），多进程默认被禁用；必须改用--socket+ Nginx 才能真正并发
为什么不能只靠threads提升并发？
threads = 2 看似简单，但在 CPython 下受 GIL 限制，对 CPU 密集型任务几乎无效；对 I/O 密集型（如数据库查询、HTTP 调用）有一定帮助，但远不如多进程稳定可靠。Django/Flask 默认 WSGI 应用在单进程内是线程不安全的，尤其涉及中间件状态或全局变量时。
典型踩坑场景：用 threads = 4 替代 processes = 4，上线后出现 session 错乱、缓存命中率骤降、日志混杂。
立即学习“Python免费学习笔记（深入）”；
创建 Flask + Vue.js 全栈项目，采用单端口架构、uv 依赖管理、结构化日志和生产级前端设计。当用户要求以下操作时触发：创建新的 Flask+Vue 项目、搭建 Web 应用、构建全栈 Python+Vue 应用、初始化 Flask Web 项目、设置单端口 Flask 前后端项目。触发词：新建项目、创建项目、搭建项目、Flask项目、Vue项目。
- 优先设
processes = N（N 通常为 CPU 核数 × 1.5～2，如 4 核机器设 6～8） -
threads建议保持 1 或 2，除非确认应用完全线程安全且大量阻塞 I/O - 避免同时设高
processes和高threads，内存开销会指数级增长
socket模式才是多进程生效的前提
如果你还在用 http = :8000 或 --http :8000 启动 uWSGI，那无论 processes 设多少，实际只有 1 个进程处理请求——因为 http 模式是单进程内置 HTTP 服务器，不走 uWSGI 协议调度。
正确做法是让 uWSGI 只监听 Unix socket 或 TCP socket（如 127.0.0.1:9090），由 Nginx 转发请求。这时 processes 才真正参与负载分发。
- 配置示例：
socket = /tmp/uwsgi.sock（推荐 Unix socket，更快更安全）或socket = 127.0.0.1:9090 - Nginx 的
location /块里必须用include uwsgi_params;并指向同一 socket - 记得给 socket 文件设权限：
chmod-socket = 664，否则 Nginx 无法连接
进程数设置不当会导致 OOM 或响应延迟
每个 uWSGI 进程都会加载完整 Python 环境和项目代码，内存占用不是线性叠加。比如单进程占 120MB，开 8 个进程不等于 960MB，可能因共享库复用只到 600MB 左右；但若项目用了大模型或缓存，就很容易超限。
容易被忽略的点：max-requests 和 reload-on-rss 必须配合使用，否则长运行进程会内存泄漏累积。
-
max-requests = 2000：每个进程处理 2000 个请求后自动重启，释放内存 -
reload-on-rss = 512：进程 RSS 内存超过 512MB 时自动重启（单位 MB） -
vacuum = true：进程退出时自动清理 socket、pid 文件等临时资源 - 务必配
die-on-term = true，否则systemctl stop时进程可能残留
