异步函数接口设计需清晰表达异步性、聚焦业务意图、明确错误分类、隔离阻塞操作。应通过命名约定（如fetchUser）、统一返回Promise、避免参数混用同步/异步行为、封装底层细节、定义领域异常、结构化部分失败结果，并杜绝内部阻塞调用。
异步函数接口是否清晰，直接决定代码后续能不能轻松读懂、修改和测试。关键不是堆砌async和await，而是让调用者一眼就明白：它要做什么、要不要等、会不会失败、边界在哪。
接口语义必须显式表达“异步性”
一个函数名或签名如果让人猜不出是否要await，就是设计缺陷。比如fetchUser()和fetchUserAsync()，后者更安全；但更好的做法是统一用动词+过去分词结构，如getUser()（同步）与fetchUser()（异步），靠命名约定建立团队共识。
- 避免在同一个函数里通过
sync=False参数切换行为，这混淆了接口契约 - 不要把
await藏在内部逻辑里却不暴露——调用方必须能明确判断是否需要挂起 - 如果函数可能同步返回、也可能异步返回（比如缓存命中时同步，未命中时异步），应统一包装为
Promise或Task，保持调用方式一致
参数设计要聚焦意图，不暴露实现细节
异步函数的参数不该包含线程池大小、超时重试策略这类底层机制，除非调用方真的需要控制它。业务层接口应只传递“做什么”，而不是“怎么做”。
- 把超时时间作为可选参数（如
timeout=30.0），而非强制要求传入loop或executor - 避免让调用方传入回调函数——这是回调地狱的根源；用
await+ 异常捕获替代 - 批量操作类接口（如
fetchUsers(ids)）默认应并发执行，但提供sequential=True开关供调试或限流，而不是反过来
错误与状态必须可预期、可区分
异步失败不能只抛Exception，而应让调用方容易识别是网络问题、权限不足，还是业务校验失败。尤其当多个异步步骤串联时，错误来源必须清晰。
- 定义领域相关的异常类型，如
UserNotFoundError、RateLimitExceededError，而非泛化RuntimeError - 对部分失败场景（如批量请求中某些项失败），返回结构化结果（如
{success: [...], failed: [...]}），而不是直接中断整个流程 - 在文档或类型注解中标明哪些异常是预期内可恢复的，哪些会导致任务终止
协作边界要干净，不污染事件循环
一个标为async的函数，内部绝不该出现time.sleep()、requests.get()这类阻塞调用。否则表面是异步，实际卡死整个协程调度。
- 同步阻塞操作必须经
asyncify()或to_thread()等工具转为异步，且在函数文档中注明“内部已做非阻塞封装” - 长时间计算（如图像处理、加密）应主动插入
await asyncio.sleep(0)让出控制权，防止饿死其他协程 - 资源获取（如数据库连接、HTTP客户端）应通过依赖注入或上下文管理器提供，避免函数内部硬编码初始化逻辑
