fastapi的async函数未必真异步，需配合真正异步库（如asyncpg、httpx）和避免同步阻塞操作；sanic虽原生async但易漏await导致空响应；两者性能差异多源于启动配置而非框架本身。
FastAPI 的 async 函数执行是否真异步？
不是所有 async def 都能带来实际并发收益。FastAPI 本身不强制协程调度，它依赖底层 ASGI 服务器（如 uvicorn）的事件循环。如果你在路由函数里调用的是同步阻塞操作（比如 requests.get()、time.sleep() 或未加 await 的数据库驱动），整个 worker 就会被卡住——哪怕函数声明为 async。
- 必须用真正异步的库：数据库用
asyncpg或motor，HTTP 客户端用httpx.AsyncClient，文件读写用aiofiles - Pydantic 模型校验默认同步执行，高频小请求下会成为瓶颈；可考虑禁用部分校验（
validate_assignment=False）或降级到pydantic.v1 -
BackgroundTasks是安全的异步任务入口，比裸写asyncio.create_task()更可靠（自动生命周期管理）
Sanic 的 await 写法容易漏掉什么？
Sanic 路由函数是原生 async，但参数提取、响应构造全靠手动，一不留神就返回协程对象而非结果——这会导致 RuntimeWarning: coroutine 'xxx' was never awaited，且客户端收到空响应或 500 错误。
- 所有从
request取值的操作都要显式await：await request.json()、await request.args.get('q') - 响应必须是
response.json()等返回HTTPResponse实例的调用，不能直接return {"msg": "ok"} - 中间件分
request和response两个阶段，每个阶段都需await，否则中断链路
压测时 uvicorn 和 sanic 启动参数不一致会怎样？
直接对比 uvicorn main:app 和 sanic main.app 得出的 QPS 差距，90% 是启动配置差异导致的，不是框架本身能力差。Sanic 默认单进程，Uvicorn 默认单 worker，而两者多进程/多线程模型也不同。
- 公平对比必须固定并发模型：
uvicorn main:app --workers 4vssanic main.app --workers 4 - Sanic 推荐启用
uvloop（sanic --uvloop main.app），否则默认 asyncio 事件循环性能打七折 - 两者都应关闭调试模式（
--debug False/--dev False），否则日志和重载逻辑严重拖慢
真实业务中谁更容易写出“伪异步”代码？
FastAPI 更容易写出表面异步、实际串行的代码——因为类型注解和自动解析掩盖了阻塞点；Sanic 则更直白，错在哪一眼可见，但容错率低。
- FastAPI 常见陷阱：
def写成async def却调用同步 DB 驱动；依赖注入函数里混用time.time() - Sanic 常见陷阱：忘记
await第三方协程、用json.loads()解析 request.body（应先await request.body()再解析） - 数据库连接池没复用才是最大瓶颈：Sanic 默认无内置池，
asyncpg.create_pool()必须全局复用；FastAPI 的Depends可封装池实例，但若每次请求都新建连接，性能反不如 Sanic
框架层的差异在简单场景下明显，一旦接入数据库、缓存、外部 API，真正的瓶颈几乎总是 IO 驱动和连接复用策略，而不是 @app.get 底下那行 async def。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
