FastAPI不支持单个endpoint同时注册同步和异步实现，需通过逻辑抽离+双endpoint、统一用async endpoint内部适配、或运行时动态选择（不推荐）三种方式实现兼容；推荐方式一是分离核心逻辑并分别定义sync/async endpoint。
FastAPI 本身不支持单个 endpoint 同时注册同步和异步两种实现方式——你必须明确选择一种。但你可以通过几种实用方式，让同一个逻辑既能被同步调用、也能被异步调用，同时保持 endpoint 接口一致。核心思路是：**把业务逻辑抽离为可复用的函数，并根据需要包装成 sync 或 async endpoint**。
方式一：逻辑分离 + 双 endpoint（推荐）
将核心处理逻辑写成普通函数（同步），再分别定义 sync 和 async endpoint 调用它。适合逻辑本身不涉及 I/O，或你希望对同步/异步路径有完全控制。
示例：
# core.py
def process_data(name: str) -> dict:
# 纯 CPU 或轻量逻辑，无 await
return {"message": f"Hello, {name}!"}
main.py
from fastapi import FastAPI
from core import process_data
app = FastAPI()
@app.get("/sync")
def sync_endpoint(name: str):
return process_data(name)
@app.get("/async")
async def async_endpoint(name: str):
即使逻辑是同步的，async endpoint 也能正常工作
return process_data(name)
方式二：统一用 async endpoint，内部自动适配
FastAPI 的 async endpoint 可以安全调用同步函数（无需 await），也能 await 异步函数。因此，最简单稳健的做法是：**所有 endpoint 都写成 async，内部按需调用 sync 或 async 逻辑**。
- 调用纯同步函数：直接执行，不加 await
- 调用 async 函数（如数据库查询）：用 await
- 逻辑复杂时，可用 asyncio.to_thread（Python 3.9+）或 loop.run_in_executor 将阻塞操作转为异步调用
示例：
@app.get("/unified")
async def unified_endpoint(name: str, use_db: bool = False):
if use_db:
# 假设 db_query 是 async 函数
result = await db_query(name)
else:
# 直接调用同步函数
result = process_data(name)
return result
方式三：运行时动态选择（不推荐，仅作了解）
理论上可通过依赖注入或中间件判断请求头、参数等，动态决定走 sync 还是 async 分支。但 FastAPI 的路由机制在启动时就绑定函数类型，无法在运行时切换协程状态。强行混用会导致：
- 同步函数被 await → 报错
TypeError: object X can't be used in 'await' expression - 异步函数被直接返回（不 await）→ 返回 coroutine 对象，FastAPI 会尝试 JSON 序列化它，失败
所以不要试图在一个函数体内“条件性 await”，也不要在同一路径上动态替换 handler。
关键提醒
- FastAPI 会根据你定义的函数是否带 async def 自动选择事件循环调度方式
- 同步 endpoint 会被运行在线程池中（默认），不影响主线程；异步 endpoint 在主 event loop 中执行
- 混合 I/O 密集型（DB、HTTP 调用）和 CPU 密集型逻辑时，优先用 async endpoint + to_thread 避免阻塞
- 别为了“看起来支持两种”而牺牲可读性和可维护性——明确区分更可靠
