Waitress启动CPU占用高、响应慢的根源是默认单线程（1线程）且未调优，须显式设threads=CPU核数×2（如4核设8）、connections≥1000，并用Python脚本而非waitress-serve启动，同时绑定host='0.0.0.0'、配好Windows防火墙及数据库连接池。
waitress 启动时 CPU 占用高、响应慢
waitress 默认单线程 + 单进程，Windows 上跑默认配置容易卡在 1–2 个并发请求就变慢。这不是 Flask 本身的问题，而是 waitress 的启动参数没调对。
-
threads必须显式设置，建议设为 CPU 核心数 × 2（如 4 核机器设threads=8），否则默认只开 1 个线程 -
connections建议设为1000或更高，避免连接排队；Windows 默认 socket backlog 较小，不调这个会丢连接 - 别用
waitress-serve命令行直接跑——它不支持threads和connections参数，必须写 Python 脚本启动
正确做法是新建 run.py：
from waitress import serve from app import app # 替换为你的实际模块名 serve(app, host='0.0.0.0', port=5000, threads=8, connections=1000)
Windows 防火墙和端口监听失败
服务明明跑起来了，但浏览器访问超时或拒绝连接，大概率是 Windows 防火墙拦了端口，或者 host 绑定错了。
-
host='127.0.0.1'只允许本机访问，生产环境必须用host='0.0.0.0' - PowerShell 执行防火墙规则时，
New-NetFirewallRule必须以管理员身份运行，且-LocalPort要和serve()中的port一致 - 如果云服务器（如 Azure/AWS），还要检查安全组是否放行对应端口——Windows 防火墙开了 ≠ 外网能通
数据库连接池耗尽导致请求阻塞
Flask + SQLAlchemy 在 Windows 上长时间运行后，偶尔出现请求卡住几秒甚至超时，常见原因是 SQLite 文件锁死，或 PostgreSQL 连接未复用。
立即学习“Python免费学习笔记（深入）”；
- SQLite 不适合多并发：Windows 对文件锁更严格，
SQLALCHEMY_POOL_SIZE设再大也没用，生产环境建议换postgresql://或mysql:// - PostgreSQL 必须配连接池：
app.config['SQLALCHEMY_ENGINE_OPTIONS'] = {'pool_size': 10, 'max_overflow': 20} - 环境变量里不要硬写密码，用
os.environ.get('DATABASE_URL')，避免配置文件被意外提交或泄露
NSSM 注册服务后启动失败或崩溃退出
NSSM 把 python run.py 包成服务后，经常“启动成功”但立刻停止，日志里只显示“exit code 1”，根本原因通常是路径或环境没加载全。
- NSSM 的“Startup directory”必须填项目根目录（不是 Python 安装目录），否则
from app import app会报ModuleNotFoundError - “Service Environment”里要手动加
PATH和PYTHONPATH：把虚拟环境的Scripts目录和项目根目录都加进去 - 别让 NSSM 直接调用
venv\Scripts\python.exe—— 它可能找不到激活后的 pip 包，改用绝对路径调用venv\Scripts\python.exe并确保第一参数是run.py的绝对路径
最易被忽略的一点：waitress 服务一旦因异常退出，NSSM 默认不会重试——得在 NSSM GUI 的 “Service Recovery” 页里勾选“Restart the Service”并设“First failure”为立即重启，否则一次数据库连不上就整个服务挂了。
