绝对导入能绕过__package__依赖，避免直接运行脚本时崩溃；它不依赖运行上下文，兼容CI/CD、测试框架及IDE，重构可控且工具链支持更成熟。
绝对导入能绕过 __package__ 依赖，避免直接运行脚本时崩溃
相对导入要求模块必须有有效的 __package__ 属性，而该属性只在模块被 python -m 方式加载时才被正确设置。一旦你双击运行 pkg/submod.py 或在 IDE 里点「Run」，__name__ 就是 '__main__'，__package__ 是 None，此时任何 from .utils import helper 都会立刻抛出 ImportError: attempted relative import with no known parent package。
企业级项目里，测试文件、CLI 入口、数据处理脚本经常需要独立执行——它们不是“被导入的包成员”，而是“启动点”。绝对导入不依赖运行上下文，from myproject.utils import helper 在哪儿跑都行。
CI/CD 和测试框架对相对导入行为不一致
pytest、tox、nox 这些工具默认以模块方式运行测试（python -m pytest），但具体是否把 test_*.py 视为包的一部分，取决于目录结构、pyproject.toml 配置和是否启用 --import-mode=importlib。有些环境里 from ..src import main 能过，换一台机器或升级 pytest 就报错。
绝对导入把路径决策收归统一：所有导入都从项目根开始。只要 myproject 在 sys.path 里（用 pip install -e . 或临时加路径），就稳。
立即学习“Python免费学习笔记（深入）”；
- CI 中推荐用
pip install -e .而非python setup.py develop（已弃用） - 本地开发时，别把 IDE 的 “Add content root” 当成 Python 的
sys.path—— 它们不等价 - 如果用 Poetry，确保
poetry install后poetry run python -c "import myproject"不报错
重构时绝对导入的破坏性更可控
相对导入看似“移动包不用改导入”，但实际藏着陷阱：比如把 pkg/a.py 移到 pkg/v2/a.py，原来 from ..utils import x 就变成跨两级跳，容易越界；再比如合并两个包，相对路径关系瞬间失效。
绝对导入虽然要批量替换字符串，但它是可搜索、可验证、可自动化（用 sed 或 AST 工具）的。更重要的是，它的错误是显性的：ModuleNotFoundError 明确告诉你缺哪一层，而不是静默导入错模块。
团队协作中，新成员看 from myproject.api.v1.handlers import UserHandler，一眼知道代码在哪；而 from ...models import User 得先翻三层目录才能确认是不是自己想的那个 models。
IDE 和静态分析工具对绝对导入支持更成熟
PyCharm、VS Code + Pylance、mypy、ruff 默认按绝对路径解析导入。相对导入在函数体内、条件分支里、或者动态拼接字符串时，很容易被误判为无效或不可达。
例如这段代码：
if DEBUG:
from .debug import tracer
else:
from .prod import tracer
mypy 会警告 Relative import outside of package，因为无法保证 DEBUG 在类型检查时为真；而绝对导入写成 from myproject.debug import tracer，无论是否启用 DEBUG，路径都是确定的。
