python导入包的几种方法

import os 这行代码，导入大概是种方每个 Python 开发者每天都要敲上几十遍的东西。但你有没有想过，导入这背后的种方导入机制，其实藏着不少门道？导入

最直白的做法，就是种方把整个模块拽进来。比如你要用 JSON 处理数据，导入直接 import json，种方然后每次调用都得写 json.dumps()。导入这方式干净利落，种方但有个小毛病——如果你的导入代码里到处是 json.dumps()、json.loads()，种方手写起来总觉得冗余。导入我见过不少新手，种方为了省事，导入干脆把模块里所有函数都塞进全局命名空间，结果自己的变量跟模块里的函数撞了名字，排查半天才发现是命名冲突。这种坑，踩过一次就长记性了。

于是就有了 from json import dumps 这种局部导入。好处是调用时直接写 dumps()，代码清爽不少。但坏处也明显——你根本不知道这个 dumps 是从哪来的。要是哪天你同事在文件顶部加了个 from time import dumps（虽然 time 模块没这函数，但道理一样），代码直接崩给你看。我自己的习惯是，如果模块名短且常用，比如 os、sys，就全量导入；如果模块名长，比如 collections.OrderedDict，就用局部导入。这纯属个人偏好，没有绝对的对错。

还有种玩法叫别名导入。你嫌 import numpy 每次写太长，那就 import numpy as np。这招在数据科学领域几乎是标配。但别滥用——我见过有人把 import pandas as pd 写成 import pandas as p，省了两个字母，结果三个月后自己回来看代码，愣是没反应过来 p 是什么东西。别名要短，但得有辨识度。np、pd、plt 这种约定俗成的，随便用；自己发明的缩写，最好在文件开头注释一句。

如果你只想导入模块里的几个特定函数，from module import func1, func2 也能搞定。这招在写脚本时特别管用。比如你只需要 math 模块的 sqrt 和 pi，那就只导入这两个，解释器加载速度会快那么一丁点——虽然现代计算机上这点差异几乎感觉不到，但代码的意图更明确了。不过要小心，如果模块里有 __init__.py 定义了 __all__，那 from module import * 的行为会被它限制。这个坑我踩过，写包的时候没定义 __all__，结果用户 from mypackage import * 把所有内部函数都导出来了，连那些以下划线开头的私有函数都露了脸。

再说说包内导入。你写了个包，里面有多个子模块，子模块之间要互相引用。相对导入是正解：from . import sibling 或者 from .sibling import func。点号表示当前目录，两个点表示上级目录。但这里有个大坑——如果你直接把子模块当脚本运行，比如 python mypackage/submodule.py，相对导入会直接报错，因为 Python 把 submodule.py 当成了顶层模块。解决方法是 python -m mypackage.submodule。这问题我当年调了一下午才搞明白，最后发现是运行方式不对。

还有个冷门但实用的技巧：动态导入。用 importlib.import_module('os')，字符串传模块名。这在写插件系统或者配置驱动代码时很有用。比如你有个配置文件写了要加载哪个模块，程序运行时根据配置字符串动态导入。但要注意，动态导入的模块如果不在 sys.path 里，得先手动加路径。而且这种导入方式 IDE 无法自动补全，代码可读性也差点。

最后提一句 __import__ 函数，这是所有导入机制的底层实现。平时基本用不到，但如果你想写个极简的模块加载器，或者对 Python 的导入协议做黑魔法操作，就得碰它。我自己只在写测试框架时用过一次，用来模拟模块不存在的情况。

导入这事的核心原则就一条：让代码的依赖关系清晰可查。别为了省事把命名空间搞成一锅粥，也别为了追求某个技巧而牺牲可读性。Python 的哲学是显式优于隐式，导入方式的选择，本质上是在表达你的代码意图——你希望读者怎么理解这些模块之间的关系。