循环导入本质是模块初始化死锁，非模块缺失；因python顺序执行模块代码并缓存空壳对象，a导入b、b又顶层导入a中未定义的符号时即报错，延迟导入至函数内可避开初始化依赖链。
循环导入不是模块找不到，而是 Python 在初始化模块时被卡住了——ImportError: cannot import name 'X' from partially initialized module 'Y' 这类报错，基本可以断定是 A 导入 B、B 又在顶层试图导入 A 中还没执行完的符号。
为什么模块顶层 from X import Y 会触发循环失败
Python 加载模块是顺序执行 + 单次缓存：第一次 import A 时，解释器逐行跑 A.py，同时把空壳 A 对象塞进 sys.modules；这时如果 A 里有 from B import func，就跳去加载 B；而 B 若又写 from A import Class，就会回头找 A ——但此时 A 还没执行完，Class 根本不存在，直接抛错。
常见诱因包括：
-
__init__.py里做跨模块from ... import ... - 两个模块都用
from module import Class互相引用类 - IDE 自动补全或重构工具没注意导入位置，把
import插到了模块顶部
把 import 挪进函数里为什么能破环
函数内部的 import 是运行时行为，模块已加载完毕，不再参与初始化阶段的依赖解析。只要不是用于模块级变量赋值或 __all__，它就是最轻量的解法。
例如：
# a.py
def do_something():
from b import helper # ✅ 延迟到调用时
return helper()
<h1>b.py</h1><p>def helper():
from a import do_something # ✅ 同理
return do_something()
</p>
注意：
- 不能用于给模块级常量赋值，比如
DEFAULT_CONFIG = from a import config是语法错误 - 每次调用都会查一次
sys.modules，但开销可忽略 - 可读性会下降——依赖关系藏在函数深处，需要翻代码才能发现
什么时候该拆出 types.py 或合并模块
如果两个模块总是一起改、一起测、git log 显示它们频繁出现在同一 commit，说明它们本就不该分开——合并是最干净的方案；反之，如果 A 是业务逻辑、B 是数据模型，职责分明但又必须交互，那就该抽一个中间层。
拆接口层的实操要点：
- 新建
shared.py或protocols.py，只放class UserProtocol:、ConfigDict = Dict[str, Any]这类声明，不放实现 - A 和 B 都只
import shared，不再互导 - 类型检查（如 mypy）能验证协议兼容性，运行时零成本
合并模块的注意事项：
- 外部所有引用要批量更新，别漏掉测试文件或
__init__.py - 如果其他模块只用了原 A 的一部分，合并后可能意外获得 B 的符号，需靠
__all__控制导出
真正容易被忽略的是：循环导入往往不是孤立问题，而是模块职责模糊的信号。修复时别只盯着报错那行 import，先看这两个模块是否真的该彼此知道对方的存在。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
