按需导入：避免 from xxx import *，使用具体导入

说实话，我最早写 Python 的时候，也图省事直接用 from xxx import *。当时心想：反正要用那么多函数，一次性全导进来多爽。结果呢？项目跑了一个月，突然发现某个函数的行为莫名其妙变了——查了半天，原来是另一个模块里也有同名函数，被覆盖了。那感觉，真叫一个扎心。

后来我养成一个习惯：永远别偷懒用星号导入。你可能会问，到底坏在哪？嗯，这得从头捋一捋。

一、import * 的三宗罪

问题	具体表现	后果
命名空间污染	把模块中所有公开名称塞进当前作用域	极易覆盖已有变量或函数，debug 到崩溃
性能开销	Python 解释器需要加载并绑定所有名称	启动变慢，内存占用增加
可读性崩塌	读者不知道这个函数来自哪个模块	代码像一团浆糊，维护成本飙升

我在一次代码评审中遇到过这样的情况：同事写了一个 from utils import *，结果项目里有几十个工具函数都暴露出来了。新同事想找一个叫 parse_date 的函数，满世界搜不到来源——最后发现是被 utils 里的另一个函数覆盖了。你说冤不冤？

二、具体导入的正确姿势

说白了，就是明确写出你要导入的每个名字：

# ❌ 不推荐
from os import *

# ✅ 推荐
from os import path, listdir, makedirs

# ❌ 不推荐
from requests import *

# ✅ 推荐
from requests import get, post, Session

我个人习惯在 import 行里只放 3～5 个最常用的对象。如果超过 5 个，说明这个模块的职责可能过重了——要么拆模块，要么用别名引入整个模块然后用 module.name 调用。

举个例子，我曾经重构过一个工具库：

# 重构前
from mytoolkit import *
# 然后到处用 parse_json, clean_text, validate_email ...

# 重构后
from mytoolkit import parse_json, clean_text
from mytoolkit.validation import validate_email

你看，这样每个函数从哪来，一目了然。而且 mytoolkit 的命名空间也不乱了。

三、避坑指南：我曾经踩过的几个坑

• __all__ 不等于安全：有人以为模块里写了 __all__ 就能控制 import * 只导入部分名字。但 __all__ 只是约定，第三方库不一定遵守，而且容易漏掉私有函数。别依赖它。
• 别和系统模块打架：比如 from math import * 会把 sin、cos 等几十个名字全都拉进来。如果你自己又定义了一个 sin 变量，后面调用时就蒙圈了——这个 sin 到底是 math 的还是我自己的？
• 小心动态导入库：有些库（比如 numpy）的 __init__.py 里会做大量动态属性加载。你 import * 时可能触发意想不到的副作用。我记得有一次项目部署到 Docker 里，一个 from pandas import * 把内存吃爆了——因为 pandas 内部导入了大量工具模块。

四、具体导入 vs 星号导入：一张图说明白

下面这张图对比了两种导入方式的执行流程和后果，你可以直观看到差异：

五、什么时候可以破例？

我个人觉得，唯一合理的场景是 交互式环境 里做快速探索。比如你在 Jupyter 里临时想看看某个库的所有函数，敲一句 from math import * 比较方便。但记住：写完实验，立刻删掉，别让它混进正式代码。

另外，有些库（比如 tkinter）的官方文档里推荐使用 from tkinter import * 是因为它本身设计就得这么用——但即便如此，大型项目里也不建议。我参与过一个 GUI 工具，用了 import * 后，后来加了一个 Button 类，直接覆盖了 tkinter 的 Button，结果所有按钮都崩了。

嗯，到这里你应该明白了：具体导入不只是代码规范，更是自我保护。少写一个星号，少熬一个通宵。