Flask在Windows下不支持多进程，根本原因是Werkzeug开发服务器禁用processes参数，因Windows缺乏fork且spawn未适配；唯一可行方案是启动多个隔离实例并用反向代理分发请求。
Flask 在 Windows 下多进程表现异常，根本原因不是 Flask 本身有问题，而是 Windows 的多进程启动机制（spawn）和 Flask 默认开发服务器的运行方式不兼容——它压根就不该在 Windows 上用 app.run(processes=N) 启动多进程。
为什么 app.run(processes=N) 在 Windows 上直接报错或无效
Flask 自带的开发服务器（Werkzeug）在 Windows 上根本不支持 processes 参数。调用 app.run(processes=4) 会触发 ValueError: Processes not available on this platform 或静默忽略该参数，退化为单进程。这不是 bug，是 Werkzeug 明确禁用的行为：Windows 缺乏可靠的 fork，而 spawn 需要完整重载模块、重建解释器状态，Werkzeug 没做适配。
- 你看到的“报错”通常是
AttributeError: 'WSGIServer' object has no attribute 'processes'或直接卡死 - 即使加了
threaded=False，也改变不了底层限制——Werkzeug 的make_server在 Windows 下只允许单 worker - 试图用
gevent+multiprocess混搭，反而因 patch 顺序和 event loop 冲突导致 CPU 占用低、实际仍是串行
if __name__ == '__main__' 保护对 Flask 多进程没用，但对 DataLoader 等组件至关重要
这个判断对防止 PyTorch DataLoader(num_workers>0) 崩溃是刚性要求，但它对 Flask 本身无意义。因为 Flask 的 app.run() 不会触发子进程 spawn；真正启动多进程的是 WSGI 服务器（如 Gunicorn），而它在 Windows 上不可用。
- Gunicorn 官方明确不支持 Windows（截至 2026 年仍无原生支持）
- uWSGI 在 Windows 上需 Cygwin/WSL，生产环境不现实
- 所以你在 Windows 上看到的所有“Flask 多进程”方案，本质都是绕过标准路径：要么启多个独立
app.run()实例（不同端口），要么改用waitress（仅多线程，非多进程）
Windows 上唯一可行的“高并发”路径是多实例 + 反向代理
别纠结“一个 Flask 进程怎么变多个”，直接起多个隔离的 Flask 进程，每个绑定不同端口，再用 Nginx 或轻量级代理（如 httpx + 轮询）做负载分发。这是 Windows 下最稳定、可观察、易调试的方案。
立即学习“Python免费学习笔记（深入）”；
- 每个实例独占一个 Python 解释器，互不干扰，
if __name__ == '__main__'无需额外处理 - 避免共享内存、跨进程锁、序列化开销等复杂问题
- 注意：不能让多个实例共用同一个 SQLite 文件（会损坏），必须用 PostgreSQL / MySQL 或切换为文件锁 + JSON 序列化缓存
- 示例启动脚本：
start python app.py --port 5001、start python app.py --port 5002，再用 Nginxupstream转发
真正容易被忽略的点是：你以为在解决“Flask 多进程”，其实是在对抗 Windows 的进程模型。与其硬套 Linux 部署逻辑，不如接受它的约束——用多个干净、隔离、可重启的 Flask 实例，比在一个进程里塞满线程+协程+子进程更可靠。
