Python循环导入本质是模块初始化时相互等待，解决关键是打破强依赖链：①推迟导入至函数内；②重构提取公共模块；③启用延迟注解；④警惕__init__.py和相对导入引发的隐式循环。
Python中循环导入本质是模块在初始化过程中相互等待对方完成加载，导致ImportError或AttributeError。关键不在于“禁止导入”，而在于打破初始化时的强依赖链。
推迟导入：把import移到函数/方法内部
这是最常用、最安全的解法。模块顶层不触发导入，只在真正需要时才加载，此时双方通常已完成初始化。
- 适用于工具函数、非构造逻辑、条件分支中的依赖
- 例如：
utils.py需要调用models.py里的类做数据验证，就把from models import User写在验证函数里，而不是文件顶部 - 注意：频繁调用的函数中重复导入有轻微开销，但CPython会缓存已导入模块，实际影响极小
重构依赖：提取公共模块或抽象接口
当A依赖B、B又依赖A，往往说明职责边界模糊。把共用的数据结构、协议定义、基础配置抽到第三个模块（如core.py或types.py），让A和B都只依赖它。
- 适合长期维护项目，能提升可读性和测试性
- 例如：用户服务和订单服务互相引用模型，可将
UserSchema和OrderStatus移到shared/schemas.py - 避免过度拆分——不是所有循环都需要抽离，简单场景用推迟导入更直接
使用字符串标注类型（PEP 563 + from __future__ import annotations）
类型提示中的类名若用于循环模块，直接写类名会触发导入。启用延迟注解后，类型仅作字符串保存，运行时不执行解析。
立即学习“Python免费学习笔记（深入）”；
- 在文件开头加
from __future__ import annotations - 类型注解中可用未导入的类名，如
def get_profile(user: User) -> dict:，即使User尚未导入也合法 - 配合mypy等工具仍能做静态检查，不影响开发体验
警惕隐式循环：__init__.py 和相对导入
包结构中，__init__.py自动导入子模块容易埋下隐患；相对导入（from . import xxx）在跨层级引用时也可能绕过预期路径。
- 精简
__init__.py，只暴露对外API，避免在其中导入深层模块 - 调试时用
python -v观察实际导入顺序，确认是否意外触发了某模块 - 必要时改用绝对导入（
from mypackage.submodule import func），语义更清晰，也更容易追踪依赖
