根本原因是PyMongo实例在应用上下文外被调用，多进程下各worker独立初始化且若在全局作用域创建PyMongo对象，会因缺失app.context触发RuntimeError；同时authSource未指定或连接池配置不当会导致认证失败或连接耗尽。
Flask多进程启动时PyMongo连接报错 RuntimeError: Working outside of application context
根本原因是 PyMongo 实例在应用上下文外被调用，而多进程（如 gunicorn 启动多个 worker）会让每个子进程独立初始化，但 PyMongo 对象若在模块顶层或工厂函数外创建，就会在无上下文时触发 RuntimeError。
- 别在
app = Flask(__name__)之前或全局作用域里写mongo = PyMongo(app) - 工厂模式下，必须等
create_app()返回 app、完成app.config加载后，再实例化PyMongo - 确保所有数据库操作都发生在请求生命周期内（即视图函数、before_request 钩子等），而非模块导入阶段
gunicorn 多 worker 下 PyMongo 连接池耗尽或认证失败
每个 worker 进程都会持有一个独立的 MongoClient 实例，若未显式复用或配置连接池，可能快速占满 MongoDB 的最大连接数（默认 100），或因认证数据库（source）未指定导致静默超时。
- 确认
MONGO_URI中已包含认证数据库名，例如"mongodb://user:pass@host:27017/mydb?authSource=admin"——authSource=admin是关键，不能省略 - 避免在每次请求中新建
MongoClient；用PyMongo扩展时，它内部会复用底层mongo.cx，但前提是实例只初始化一次 - 检查 MongoDB 服务端最大连接数：
db.runCommand({connectionPoolStats: 1})，若totalCreated持续飙升，说明客户端未复用连接
多进程下 ObjectId 查询失效或数据不一致
不是连接问题，而是并发写入时未处理好文档唯一性或读取时机，容易误判“查不到”，实际是写入与查询时间差 + 进程间缓存/状态隔离导致。
-
insert_one()后立即find_one({"_id": inserted_id})，务必传ObjectId类型，不是字符串：from bson import ObjectId; mongo.db.coll.find_one({"_id": ObjectId(inserted_id)}) - 避免在多进程共享变量里缓存查询结果（如全局 dict），各 worker 进程内存隔离，缓存不同步
- 高并发插入相同业务键（如
email）时，建议提前建唯一索引：mongo.db.users.create_index("email", unique=True)，靠数据库拒绝重复，而非应用层判断
如何验证每个 worker 是否真正连上了 MongoDB？
不能只测单个进程，要模拟真实部署场景。最直接的办法是在视图里打印连接状态和当前进程 ID。
- 加一个调试路由：
@app.route("/health/db")，里面执行mongo.db.command("ping")并返回os.getpid() - 用
gunicorn --workers=4 --preload app:app启动（--preload确保每个 worker 初始化时都加载一次），访问该路由，看是否 4 个不同 PID 都返回{"ok": 1.0} - 若某个 PID 报
ServerSelectionTimeoutMS或Authentication failed，说明该 worker 的连接参数（尤其是authSource）有误，或环境变量未透传到子进程
