uwsgi的--preload预加载应用模块顶层代码（如导入、配置初始化、连接池创建），但不执行路由内动态import或框架启动逻辑，需配合--master且不可与--lazy-apps共存。
uWSGI的--preload到底预加载了什么？
它不是“把所有import语句都执行一遍”，而是让uWSGI在fork工作进程前，先运行一次你的应用模块（比如app.py），完成顶层导入、初始化配置、建立数据库连接池等一次性动作。这样每个worker进程启动时，就不用再重复这些开销。
常见错误是以为加了--preload就能解决一切慢问题——其实它只对“启动时必做”的初始化有效；如果模块是在路由函数里动态import的（比如import torch），它完全不生效。
- 必须配合
--master使用，否则预加载无意义 - 不能和
--lazy-apps共存，两者逻辑冲突 - 若应用里有全局状态（如未加锁的单例、修改
sys.path），预加载可能引发多进程间竞争
Gunicorn的--preload行为更保守
Gunicorn的--preload只做一件事：在主进程里执行一次import your_app，确保语法正确、顶层代码能跑通，但不会触发Flask/Django的create_app()调用或实际初始化。它更像一个“健康检查”，而不是真正的预热。
所以你看到Gunicorn加了--preload后启动快了100ms，但首次请求仍卡顿——那是因为app = create_app()还在worker里执行，数据库连接、缓存客户端、日志配置全都没准备好。
- 适合用于快速发现
ImportError或语法错误，避免worker反复崩溃重启 - 对真实首请求延迟改善有限，需配合
on_starting钩子手动初始化 - 在Django项目中，
--preload几乎没用，因为django.setup()必须在每个worker中调用
真正有效的预加载：绕过框架封装直接控制
别依赖uWSGI/Gunicorn的黑盒机制。把初始化逻辑拆出来，显式控制何时加载、加载哪些模块：
例如，在app.py顶部写：
if __name__ == '__main__':
# 仅当直接运行时才预加载（本地调试）
pass
else:
# uWSGI/Gunicorn import时执行
import numpy # 确保C扩展提前链接
from mypkg.db import init_pool
init_pool() # 主动建连接池，而非等第一次请求
这种写法不依赖任何参数，清晰可控。关键点：
- 把耗时操作（如
torch.hub.load、大模型加载）移到if __name__ != '__main__'分支里 - 避免在预加载阶段调用
app.run()或app.listen()这类启动函数 - 用
os.getenv('MODE') == 'prod'区分开发/生产，防止本地调试时误加载大模块
为什么有时候预加载反而更慢？
预加载不是银弹。它会把本该懒加载的模块提前塞进内存，尤其当你用了tensorflow或pytorch这类巨型包时，每个worker进程的RSS（常驻内存）会立刻涨几百MB，触发系统OOM Killer或拖慢整体调度。
典型症状：
- uWSGI日志里出现
WARNING: you have enabled the preloading, but you haven't set the master process. This is not recommended. - top命令看到多个worker的RES列异常高，且随worker数线性增长
- 首次请求延迟下降了，但第100个并发请求开始大量超时——内存带宽被打满
这时候应该放弃全局预加载，改用按需加载+进程内缓存，比如用functools.lru_cache包装模型加载函数，保证每个worker只加载一次。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
