答案是：需明确具体卡点，如WSGI/ASGI混用、异步中g对象丢失、iterator()误用等，并针对性解决。例如uvicorn嵌套启动应避免asyncio.run()在已有loop中调用；Flask的g不跨线程/协程，须显式传参；Django的iterator()仅在未求值且单次遍历时有效。
这标题没有实际信息量，不是学习路径的标识，也不是技术问题的描述——它既不指向某个具体框架机制，也不关联常见报错或性能瓶颈。真正需要的，是明确你在哪一步卡住了：是 WSGI 和 ASGI 混用导致服务起不来？还是 Flask 的 request.context 在异步视图里取不到数据？又或者 Django 的 select_related 和 prefetch_related 选错了导致 N+1 查询爆炸？
为什么 uvicorn 启动 FastAPI 却提示 RuntimeError: asyncio.run() cannot be called from a running event loop
这是典型的开发环境嵌套启动错误，多见于在 Jupyter、IPython 或已运行 asyncio 的进程中直接调用 uvicorn.run()。
- 生产部署时应使用命令行启动：
uvicorn main:app --reload，而非在 Python 脚本里写uvicorn.run(...) - 若必须在脚本中启动（如测试场景），需确保未处于已有 event loop 中：
import asyncio from uvicorn import Config, Server
config = Config(app="main:app", host="0.0.0.0", port=8000, reload=True) server = Server(config)
显式新建 loop，避免复用当前 loop
asyncio.run(server.serve())
-
--reload在 Windows 下依赖watchfiles，若提示找不到 watcher，需手动pip install watchfiles
Flask 的 g 对象在多线程/多进程下为何丢失上下文
g 是请求生命周期内的全局命名空间，但它的生命周期严格绑定于 RequestContext，不是进程或线程级变量。
立即学习“Python免费学习笔记（深入）”；
- 在
threading.Thread或multiprocessing.Process中访问g，必然为空或抛RuntimeError -
异步任务（如
asyncio.create_task）也不继承g，需显式传参或改用contextvars.ContextVar - 正确做法是把需要的数据作为参数传入子任务，而不是依赖
g跨作用域传递：from flask import g, Flask import asyncio
app = Flask(name)
@app.route('/test') def test(): g.user_id = 123
❌ 错误：子任务看不到 g
# asyncio.create_task(background_job()) # ✅ 正确：显式传值 asyncio.create_task(background_job(user_id=g.user_id)) return 'ok'
async def background_job(user_id): print(f"Processing for user {user_id}") # 而非 g.user_id
Django 中 QuerySet 的 iterator() 并没减少内存占用？
iterator() 只解决“单次查询结果集过大导致内存爆满”，但前提是：你没提前触发求值（比如用 list(qs)、len(qs)、qs[0] 或模板里遍历两次）。
- 一旦
QuerySet被求值过一次，Django 就会缓存结果，后续所有操作都从缓存读 —— 此时iterator()完全无效 - 使用场景仅限：一次性遍历且数据量极大（如导出百万行）、且确认该
QuerySet不会被重复使用 - 更稳妥的替代方案是分页 +
values_list('id', flat=True)配合in子查询，或直接用原生 SQL 流式读取
Web 开发里最耗时间的从来不是“学了多少”，而是搞清某个行为背后到底触发了哪一层机制——是 WSGI 协议限制？事件循环调度策略？ORM 缓存策略？还是 HTTP 头解析顺序？盯住那个具体函数、那行报错、那个异常堆栈，比追“第545讲”有用得多。
