Python中async def函数本质是协程函数，不能直接同步调用；应分离核心逻辑为同步函数，再分别封装异步和同步接口，以实现同一语义逻辑的双模式调用。

Python 中异步函数（async def）本质是协程函数，返回协程对象，**不能直接像普通函数那样同步调用并获得返回值**。但你可以通过封装或适配方式，让“同一语义逻辑”既支持 await 也支持同步调用——关键不是让同一个 async def 函数“自己变同步”，而是提供两种调用入口，底层复用逻辑。

推荐方案：分离逻辑 + 双接口封装

把核心业务逻辑写成普通同步函数，再分别包装出异步和同步两个接口。这是最清晰、可维护性最强的做法。

• 定义纯逻辑函数（同步）：不带 async，不涉及 await
• 定义异步包装器：async def 内部调用它（必要时用 await asyncio.to_thread(...) 处理阻塞操作）
• 定义同步包装器：def 直接调用它，或用 asyncio.run()（仅限顶层/非嵌套场景）

示例：

import asyncio
import time
✅ 核心逻辑（同步、无副作用、可复用）
def compute_heavy(x: int) -> int:
time.sleep(1)  # 模拟 CPU/IO 阻塞操作
return x ** 2
✅ 异步接口：适合在 async 上下文中 await
async def compute_heavy_async(x: int) -> int:
若 compute_heavy 是 IO 密集型，可用 to_thread 避免阻塞事件循环
return await asyncio.to_thread(compute_heavy, x)
✅ 同步接口：普通调用，无需 event loop
def compute_heavy_sync(x: int) -> int:
return compute_heavy(x)
使用方式：
await compute_heavy_async(5)   # → 25（在 async 函数内）
compute_heavy_sync(5)         # → 25（ anywhere ）

不推荐但可行：运行时判断并自动调度

用 inspect.iscoroutinefunction 或检查当前是否在 event loop 中，动态决定同步执行还是启动 loop。但易出错，且 asyncio.run() 在已有 loop 中会报错。

• 仅适用于脚本顶层、简单 CLI 工具等单次执行场景
• 嵌套调用或 Web 框架（如 FastAPI）中绝对不要用 asyncio.run()
• 无法处理“已在 async 上下文里却想同步调用”的情况（会死锁或 RuntimeError）

常见误区澄清

• 不能给 async def 函数加 @sync_and_async 装饰器让它“自动变同步” —— 协程对象必须被 await 或 asyncio.run() 驱动，否则只是个未执行的对象
• asyncio.run(coro) 不是“同步调用异步函数”的通用解法 —— 它每次新建一个 event loop，开销大，且不能在已有 loop 中调用（比如在 Jupyter、FastAPI、aiohttp handler 里会崩溃）
• 别用 loop.run_until_complete() 手动驱动 —— 你需要确保拿到的是当前 loop，且线程安全，极易出错

进阶提示：统一调用签名的工具函数

若多个函数都需要双模式，可写一个辅助函数自动生成同步/异步版本：

def make_dual(func):
    """生成 sync/async 一对函数，共享 func 逻辑"""
    async def _async(*args, **kwargs):
        return await asyncio.to_thread(func, *args, **kwargs)
def _sync(*args, **kwargs):
    return func(*args, **kwargs)

_async.sync = _sync  # 绑定为属性，方便发现
_sync.async = _async
return _async, _sync
用法
async_compute, sync_compute = make_dual(compute_heavy)
await async_compute(5)
sync_compute(5)

本质上，“既能 await 又能直接调用”不是语言特性，而是设计选择：把可复用逻辑下沉，再按需暴露接口。这样代码更健壮，也避免了运行时调度的陷阱。