Python中import module和from module import有什么区别

在 Python 中，import module 与 from module import ... 最根本的区别在于符号引入与命名空间绑定方式，而非模块本身的加载过程。无论使用哪种语法，Python 都会在底层完整加载并执行目标模块（将其缓存在 sys.modules 中），但 import module 会在当前命名空间创建指向该模块对象的名称，后续必须通过点号属性访问；而 from module import name 则直接将模块内的指定成员提取并绑定到当前作用域的同名变量上，调用时无需模块前缀。

一、底层加载机制：它们并没有“少加载代码”

许多刚接触 Python 的开发者容易产生一个直觉上的误解：认为 from math import sqrt 只加载了 sqrt 这一个函数，因此比 import math 更加节省内存或速度更快。事实并非如此。

在 Python 的导入机制中，无论是哪一种导入形式，解释器执行的操作分为固定的两步：

1. 加载与缓存阶段（全局性）：检查全局字典 sys.modules。如果该模块已被加载过，直接复用已有的模块对象；如果尚未加载，Python 会在模块搜索路径中寻找对应的源文件或字节码，开辟全新的模块命名空间并完整执行其顶级代码，最后将生成的模块对象保存在 sys.modules[module_name] 中。
2. 名字绑定阶段（局部性）：将第一步得到的对象绑定到当前文件（当前执行环境）的局部或全局命名空间中。

这两者的真正分歧仅发生在第二步：import module 将整个模块对象赋给当前作用域中的变量 module；而 from module import sqrt 则是从已加载的模块对象中取出属性 sqrt，并直接以 sqrt 为名写入当前作用域的符号表。

二、命名空间隔离与可读性差异

命名空间（Namespace）是 Python 组织代码和避免名称冲突的核心。import module 保留了命名空间的天然屏障，而 from module import ... 打破了这个屏障，将外部符号注入到当前环境中。

1. 命名冲突与覆盖风险

当项目变大或引入多个第三方库时，很多常用函数名（如 loads、parse、connect、open）可能会重复出现。观察以下两段代码的差异：

# 场景 1：使用 from module import，后导入的同名函数会静默覆盖前者
from json import loads
from my_custom_parser import loads  # json.loads 被完全覆盖了！

data = loads('{"status": "ok"}')   # 调用的是 my_custom_parser.loads，极易导致难以排查的 Bug

# 场景 2：使用 import module，依靠命名空间清晰区分
import json
import my_custom_parser

data1 = json.loads('{"status": "ok"}')
data2 = my_custom_parser.loads('some_format_text')  # 来源一目了然，杜绝冲突

使用 import module 时，每次调用都带着模块前缀。对于阅读代码的人来说，这种前缀提供了不可替代的上下文信息；而直接使用裸函数名时，读者往往需要翻到文件顶部才能弄清该函数来自哪个库，甚至是当前文件定义的本地函数。

三、状态同步与变量重新赋值的重大陷阱

这是两者在实际工程中最容易引发隐蔽错误的地方。如果被导入模块中含有全局状态变量（例如配置项、开关标志），使用不同的导入方式，对变量修改的传播行为截然不同。

1. 变量重绑定（Rebinding）的脱钩现象

假设我们有一个配置模块 config.py：

# config.py
DEBUG = False
CACHE = {"timeout": 300}

现在我们在 service.py 中尝试开启调试模式。对比两种写法：

# 做法 A：使用 import config
import config

config.DEBUG = True  # 直接修改 config 模块内部的属性

此时，任何其他同样执行 import config 的模块，在访问 config.DEBUG 时都会读取到最新的 True。因为所有模块引用的都是同一个 config 模块对象的堆内存地址。

但如果换成 from config import DEBUG：

# 做法 B：使用 from config import DEBUG
from config import DEBUG

DEBUG = True  # 陷阱！这里仅仅改变了 service.py 本地变量 DEBUG 的指针！

在 Python 中，布尔值、整数、字符串等都是不可变对象（Immutable）。赋值操作 DEBUG = True 并不是把原有的 False 变成了 True，而是将本地作用域中的变量名 DEBUG 重新指向了一个新的对象 True。而 config.py 模块内部的 DEBUG 依然指向原来的 False！其他模块再读取 config.DEBUG 时，完全感知不到这个修改。

四、循环导入（Circular Import）场景下的表现

循环导入（模块 A 导入模块 B，模块 B 又导入模块 A）是 Python 开发中常见的设计问题。在这类场景下，两种语法的容错能力存在显著差距。

1. 为什么 from ... import 极易触发 ImportError

当 Python 执行 from b import func_b 时，它要求 b 模块在当前这一时刻必须已经初始化完成并且拥有属性 func_b。如果在 b 的初始化过程中又试图回调 from a import func_a，而 a 此时刚刚执行到导入 b 的语句，其下方的 func_a 尚未被解释器读入内存，此时就会立即抛出致命错误：

ImportError: cannot import name 'func_a' from partially initialized module 'a' (most likely due to a circular import)

2. 为什么 import module 往往能够化解循环引用

如果改写为 import a 与 import b：

• 在执行到 import b 时，只要模块对象 a 已经在 sys.modules 中挂了号（哪怕还是一个空的半成品模块），b 对 import a 的调用就能顺利通过，不再报错。
• 只要具体的函数调用（如 a.func_a()）被推迟在函数内部（延迟执行时），当真正调用该函数时，两个模块都已经完整完成了顶级代码的执行。

虽然优秀的架构设计应当尽量重构消除循环导入，但在面对遗留代码或复杂双向依赖时，使用 import module 并在运行时通过点号动态获取属性，具有远高于 from ... import 的鲁棒性。

五、工程实践中的选型原则与建议

为了兼顾代码的可读性、可维护性与稳定性，业内形成了明确的模块导入最佳实践规范：

六、核心特性横向对比速查

为了方便快速回顾，下表整理了两种导入语法在各个维度的详细对比：

理解了上述机制之后，在日常编写 Python 代码时就能做出更加自信和专业的架构选择：优先使用 import module 保持清晰的命名边界与状态一致性；在模块层级过深或引入单一明确的类名时，选用 from module import Name 提升书写简洁度；并始终坚决抵制 from module import *。