Python同步代码转异步，核心不是简单加async/await，而是识别阻塞点、替换为非阻塞等价物，并重构调用链。关键在“IO密集型”场景才有明显收益，CPU密集型需配合多进程或线程。
识别可异步化的阻塞操作
真正能从异步中受益的，是那些会主动让出控制权的IO操作：网络请求、数据库查询、文件读写（需异步库支持）、消息队列通信等。纯计算、正则匹配、JSON序列化这类同步操作无法靠async加速，强行包装反而增加开销。
- HTTP请求 → 替换
requests为aiohttp或httpx.AsyncClient - Redis操作 → 改用
aioredis（v2）或redis-py4.0+ 的Redis.from_url(..., encoding="utf-8", decode_responses=True)+await - PostgreSQL → 使用
asyncpg，避免psycopg2（它不支持原生异步） - 文件读写 → 用
anyio.Path或trio.Path，或asyncio.to_thread()包裹open()（仅适用于小文件/低频场景）
分层改造：从底层IO到业务逻辑
不要一上来就重写整个服务。优先确保底层数据访问层（DB、Cache、HTTP Client）已异步就绪，再逐层向上升级调用方。中间件、路由层（如FastAPI）天然支持async def，只需把handler函数标记为异步即可。
- DAO层先改：每个数据库方法返回
awaitable，不阻塞事件循环 - Service层跟进：调用DAO时用
await，内部多个IO可asyncio.gather()并发执行 - Controller/API层最后动：FastAPI/Starlette直接支持
async def endpoint()，无需额外适配 - 避免混合调用：同步函数里
await会报错；异步函数里直接调用同步函数会阻塞整个协程——必须用loop.run_in_executor()或asyncio.to_thread()（Python 3.9+）脱钩
谨慎处理第三方同步库与状态共享
很多老库（如某些SDK、解析器、加密工具）没有异步接口。硬改不现实，应封装为线程池任务，而非在协程中直接调用。同时注意异步环境下的状态管理：全局变量、类实例属性在并发下可能被多个协程同时修改，需用asyncio.Lock保护，或改用上下文变量（contextvars.ContextVar）隔离请求级状态。
立即学习“Python免费学习笔记（深入）”；
- 调用同步函数：用
await asyncio.to_thread(sync_func, *args)（推荐）或await loop.run_in_executor(None, sync_func, *args) - 避免
time.sleep()：换成await asyncio.sleep() - 日志、配置、单例对象：确认是否线程安全；若依赖全局状态，考虑注入依赖或使用
ContextVar绑定请求生命周期 - 测试时注意：用
pytest-asyncio插件，函数标记@pytest.mark.asyncio，避免RuntimeWarning: coroutine 'xxx' was never awaited
验证与观测不能少
异步化后性能未必提升，甚至可能因协程调度开销、锁竞争、连接池配置不当而变慢。上线前务必压测对比QPS、P99延迟、内存占用和事件循环滞留时间。
- 监控
asyncio指标：如asyncio.tasks.all_tasks()数量突增，可能有协程泄漏 - 检查连接池：aiohttp、asyncpg等默认连接数较小，高并发下易出现
ConnectionPoolFull，需显式配置min_size/max_size - 避免
asyncio.get_event_loop().run_until_complete()在生产Web服务中使用——框架（如FastAPI）已管理事件循环 - 错误堆栈更长：异步异常常嵌套多层，开启
PYTHONASYNCIODEBUG=1辅助定位
