Strawberry 支持 async resolver，但必须用 async def 显式声明，且返回值为 Awaitable（如 await db.fetch_one()），不可在同步函数中使用 await 或返回未 await 的协程对象。
Strawberry 支持 async resolver 吗？支持，但必须用 async def 且返回 Awaitable
Strawberry 原生支持异步解析器，但不是“自动异步”——你得显式声明 async def，且返回值必须是可 await 的对象（比如 await db.fetch_one(...)）。如果写成 def 里调 await，Python 直接报 SyntaxError: 'await' outside async function；如果返回普通值（如字典），Strawberry 会当作同步处理，协程根本不会被调度。
实操建议：
- resolver 函数签名必须是
async def resolve_xxx(...)，不能是def resolve_xxx(...) - 所有 await 操作（数据库、HTTP 请求、文件读取）必须在
async函数内完成，不要试图在同步函数里asyncio.run()—— 这会阻塞事件循环，破坏 ASGI 生命周期 - GraphQL 字段类型声明需与实际返回值一致：比如
str字段不能返回Coroutine，必须await后解包 - 使用
strawberry.field(resolver=...)注册异步 resolver 时，确保 resolver 是协程函数对象，而非调用结果（别写成resolver=my_async_func()）
如何让 Strawberry 应用跑在 ASGI 服务器上（如 Uvicorn）
Strawberry 的 GraphQLApp（旧版叫 GraphQLView）默认就是 ASGI app，但容易忽略两点：一是没配对的服务器启动方式，二是漏掉 debug=True 以外的中间件兼容性问题。
实操建议：
- 启动命令必须用
uvicorn myapp:app --reload，其中app是GraphQLApp实例，不是strawberry.Schema -
GraphQLApp初始化时传入schema和可选graphiql=True（开发用），但生产环境应设graphiql=False并配 Nginx 或 Auth 中间件 - 若集成 FastAPI，用
app.include_router(graphql_app, prefix="/graphql")即可，无需额外包装；但注意 FastAPI 的依赖注入（Depends）不能直接用于 Strawberry resolver，得靠上下文传递 - Uvicorn 默认 workers=1，高并发下别盲目加
--workers 4——Strawberry resolver 内部若混用同步阻塞调用（如time.sleep、requests.get），会拖垮整个 worker
数据库异步调用常见错误：SQLModel + asyncpg 不行，得换 asyncpg 或 aiosqlite
很多人想用 SQLModel + Strawberry 异步，但 SQLModel 底层依赖 SQLAlchemy ORM，其默认 session 是同步的。直接在 async def 里调 session.query(...).first() 会阻塞事件循环，Uvicorn 日志里会出现 RuntimeWarning: coroutine ... was never awaited 或响应延迟飙升。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
实操建议：
- 放弃 SQLModel 同步 session，改用原生异步驱动：
asyncpg（PostgreSQL）、aiosqlite（SQLite）、或 SQLAlchemy 2.0+ 的AsyncSession+create_async_engine - 如果坚持用 SQLAlchemy，必须显式创建
AsyncSession，并在 resolver 中用async with session.begin(): ...，不能复用全局 session 对象 - 避免在 resolver 中做多层嵌套 await（比如 await A → await B → await C），考虑用
asyncio.gather()并发拉取关联数据，否则 N+1 查询问题会更严重 - 测试时用
pytest-asyncio+event_loopfixture，别用普通unittest.TestCase，否则async def test_...不会被识别
GraphiQL 调试时看不到 resolver 报错堆栈？检查 debug 和 allow_queries_via_get
开发时 GraphiQL 界面只显示 "Internal server error"，不输出真实异常，通常是因为 GraphQLApp 初始化时没开 debug=True，或者 Uvicorn 启动参数屏蔽了详细错误（如 --log-level warning）。
实操建议：
- 初始化
GraphQLApp必须传debug=True，否则 Strawberry 会吃掉异常，只返回通用错误 - GraphiQL 默认禁用 GET 请求，如果手动拼 URL（如
/graphql?query={...}）会 405，需显式设allow_queries_via_get=True - 自定义异常处理器（如捕获
ValueError）要用strawberry.schema.from_schema(..., extensions=[MyExtension])，而不是 try/except 包裹 resolver —— 后者会让 GraphQL 返回空数据而非错误节点 - 日志里出现
Task exception was never retrieved，说明某个 background task（比如发邮件、写日志）抛了异常但没被 await，得用asyncio.create_task(..., name="xxx")并监听asyncio.all_tasks()
GraphQL 异步真正的难点不在语法，而在于整个调用链路是否真正非阻塞：从 ASGI server → Strawberry resolver → DB driver → 网络 IO，任一环节夹带同步调用，都会让并发能力断崖下跌。很多人卡在“能跑”，却没意识到 time.sleep(1) 在 async resolver 里等价于锁死整个 worker。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
