FastAPI 里那些「延迟导入」的取舍
可选依赖、启动速度、循环引用——延迟导入不是坏味道,但要清楚代价。
FastAPI 里那些「延迟导...
什么时候该延迟导入
在 FastAPI 项目里,有几类依赖适合放到函数内部导入:
- 可选依赖:比如只在某个接口用到的 OCR、图像处理库
- 启动很慢的库:放在模块顶层会拖慢整个应用的启动
- 容易循环引用的模块:函数内导入可以绕开初始化顺序问题
@router.post("/ocr")
async def ocr(file: UploadFile):
import pytesseract # 只在这个接口被调用时加载
...
代价是什么
- 首次请求变慢:冷启动成本被转移到了用户身上
- 错误发现变晚:依赖没装,直到调用那一刻才报错
- 可读性下降:依赖关系不再集中在文件头部
我的判断标准
| 场景 | 建议 |
|---|---|
| 核心依赖(FastAPI、SQLAlchemy) | 顶层导入 |
| 只有少数接口用的重库 | 函数内导入 |
| 测试里需要 mock 的依赖 | 顶层导入,方便替换 |
延迟导入是一种权衡,不是一种风格。清楚代价,再用它。
评论
0 条还没有评论,来说点什么吧。