Python 的导入系统通过在执行模块代码之前立即将部分初始化的模块缓存到 sys.modules 中来解决循环依赖。该机制防止了无限递归，即模块 A 导入 B 同时 B 又导入 A，尽管它会造成属性在初始化时无法访问的窗口。
根本问题源于 Python 的执行模型，在导入期间按顺序填充模块命名空间。考虑两个模块，其中 module_a.py 包含 import module_b，后面跟有 def func(): pass，而 module_b.py 尝试调用 module_a.func()；属性查找失败，因为 module_a 存在于 sys.modules 中，但 func 尚未绑定。
# module_a.py import module_b # 执行在这里暂停，A 被缓存但为空 def important_function(): return "critical data" # module_b.py import module_a # 引发 AttributeError: module 'module_a' 没有属性 'important_function' result = module_a.important_function()
解决方案需要重构以消除循环，或采用懒加载模式。开发者可以将导入语句移入函数定义中，使用 importlib 进行动态导入，或将共享依赖重构到一个双方都导入的第三模块中。
我们的 FastAPI 微服务因 database.py（包含连接池）和 models.py（定义 SQLAlchemy ORM 类）之间的循环导入而受到影响。数据库模块导入模型以执行初始架构设置，而模型导入数据库中的引擎用于表创建，这导致在应用程序启动时发生 ImportError，阻止了部署。
我们评估了三种不同的解决方案。将导入语句移入 create_tables() 函数解决了即时错误，但在运行时重新执行导入逻辑会引入性能开销，并且通过隐藏依赖性降低了代码可读性。创建一个包含抽象基类的 interfaces.py 模块通过依赖倒置打破了循环，尽管这需要重构并增加了小服务的间接复杂性。使用 Python 的 typing.Protocol 实现依赖注入容器使我们能在两个模块加载后注册数据库引擎，推迟了实际连接的建立，直到应用程序启动。
我们选择了依赖注入的方法，因为它保持了清晰的架构原则而不牺牲性能。该解决方案使用 FastAPI 的 Depends() 机制在所有模块初始化后将数据库会话注入路由处理程序。这消除了循环依赖，同时通过模拟注入提高了可测试性，将启动失败率降低了 100％，将集成测试设置时间减少了 60％。
为什么 if __name__ == "__main__" 无法在模块级别防止循环导入错误？
这个保护子句只控制主脚本上下文中的代码执行，而不是导入机制本身。当 Python 遇到 import module 时，它会立即加载并执行整个模块文件，直到完成后再返回，无论是否存在任何 __name__ 检查。循环导入错误发生在此加载阶段，特别是在解释器尝试解析部分构造的命名空间中的符号时，意味着该保护子句从未有机会执行或减轻失败。
from module import name 与 import module 在解决循环依赖时有什么不同？
from 语句在模块对象从 sys.modules 检索后会立即进行属性查找，但可能在模块尚未完成执行之前。当使用 import module 时，解释器返回对模块对象本身的引用，允许在循环导入链完成后再进行属性访问。这一区别解释了为什么在 import module 之后访问 module.name 成功，而 from module import name 失败，因为点表示法在访问时重新评估命名空间，而不是在初始导入期间绑定名称。
在 Python 3.3+ 中，命名空间包的变化及其对循环导入解决的影响是什么？
PEP 420 引入了缺少 __init__.py 文件的隐式命名空间包，改变了 Python 在导入期间构造模块对象的方式。传统包会立即执行 __init__.py 中的代码，提供明确的初始化边界，而命名空间包可能会在路径条目之间触发不同的加载序列。候选人常常忽视与命名空间包相关的循环导入可能导致多个模块对象表示相同逻辑模块（每个路径条目一个），在不同文件中即使使用相同的导入语句也会造成状态碎片化。