本文解析 Python 的 from A import B 语句真实执行逻辑：它先检查模块 A 是否含有属性 B；若无，则尝试导入子模块 A.B，并期望该子模块被自动挂载为 A 的属性 B；最后再次检查 A 中是否存在 B，而非直接使用 A.B 的值。
本文解析 python 的 `from a import b` 语句真实执行逻辑：它先检查模块 a 是否含有属性 b；若无，则尝试导入子模块 a.b，并期望该子模块被自动挂载为 a 的属性 b；最后再次检查 a 中是否存在 b，而非直接使用 a.b 的值。
在 Python 的导入系统中，from A import B 看似简洁，其背后却有一套精妙且易被误解的查找流程。根据官方文档描述，该语句并非简单地“导入子模块 A.B 并将其绑定到当前命名空间”，而是遵循一个明确的三步验证机制：
- 定位并加载模块 A（若未加载）；
- 检查 A 是否具有名为 B 的属性（即 hasattr(A, 'B')）；
-
若属性 B 不存在，则尝试执行隐式子模块导入 import A.B；
- 此操作会将模块 A.B 加载进 sys.modules，并通常由 A 模块自身负责将其赋值为 A.B（例如通过 from . import B 或 B = __import__('A.B') 等方式）；
- 导入完成后，再次检查 A 对象本身是否拥有了 B 属性（注意：是检查 A.B，而非直接返回 sys.modules['A.B']）；
- 若此时 A.B 仍不存在，才触发 ImportError。
✅ 正确理解的关键在于：第二次检查的对象始终是原始模块 A，而非新导入的子模块 A.B。
例如，假设目录结构如下：
foo/ ├── __init__.py └── bar.py
若 foo/__init__.py 内容为空（即未显式导出 bar），则：
from foo import bar # ❌ ImportError: cannot import name 'bar' from 'foo'
因为 foo 模块没有 bar 属性，且 foo.bar 虽可成功导入，但 foo 自身未将 bar 设置为其属性，故第二次检查失败。
而若 foo/__init__.py 改为：
from . import bar # ✅ 显式挂载 bar 为 foo 的属性 # 或等价写法：import .bar as bar
则 from foo import bar 将成功——foo.bar 被导入后，foo 对象上已存在 bar 属性，第二次检查通过。
⚠️ 补充说明（文档未明示但实际存在）：
在极少数循环导入场景下，若 A 的初始化尚未完成、无法设置 A.B，Python 还会兜底尝试从 sys.modules 中直接获取 'A.B'。但这属于实现细节，不应作为常规依赖逻辑——模块设计者必须确保 A 主动暴露所需名称，才是符合 Python 导入约定的健壮做法。
总结：from A import B 的本质是“属性驱动的导入”，而非“路径驱动”。它要求被导入模块 A 显式提供 B 这一接口（无论通过属性赋值、from . import B 或 __all__ 控制），而非仅依赖子模块物理存在。理解这一点，可避免因隐式导入行为导致的 ImportError 和调试困惑。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
