FastAPI 里那些「延迟导入」的取舍

可选依赖、启动速度、循环引用——延迟导入不是坏味道,但要清楚代价。

A
FastAPI 里那些「延迟导...

什么时候该延迟导入

在 FastAPI 项目里,有几类依赖适合放到函数内部导入:

  • 可选依赖:比如只在某个接口用到的 OCR、图像处理库
  • 启动很慢的库:放在模块顶层会拖慢整个应用的启动
  • 容易循环引用的模块:函数内导入可以绕开初始化顺序问题
@router.post("/ocr")
async def ocr(file: UploadFile):
    import pytesseract  # 只在这个接口被调用时加载
    ...

代价是什么

  1. 首次请求变慢:冷启动成本被转移到了用户身上
  2. 错误发现变晚:依赖没装,直到调用那一刻才报错
  3. 可读性下降:依赖关系不再集中在文件头部

我的判断标准

场景 建议
核心依赖(FastAPI、SQLAlchemy) 顶层导入
只有少数接口用的重库 函数内导入
测试里需要 mock 的依赖 顶层导入,方便替换

延迟导入是一种权衡,不是一种风格。清楚代价,再用它。

← 返回文章列表

评论

0 条

还没有评论,来说点什么吧。

KEEP READING

相关文章

全部文章 →