本文详解跨目录（包括跨驱动器）导入 Python 模块的规范做法，重点解决因相对导入失败导致的 ImportError: attempted relative import with no known parent package 问题，强调包结构、__init__.py 的必要性及绝对导入的可靠性。
本文详解跨目录（包括跨驱动器）导入 python 模块的规范做法，重点解决因相对导入失败导致的 `importerror: attempted relative import with no known parent package` 问题，强调包结构、`__init__.py` 的必要性及绝对导入的可靠性。
Python 的模块导入机制依赖于包上下文（package context），而非单纯的文件系统路径。当你在 B.py 中使用 from ..fC.C import func 这类相对导入时，Python 要求 B.py 必须作为某个包的子模块被以包方式执行（例如 python -m fB.B），而不能直接运行（python B.py）或被非包上下文导入（如从 A.py 直接 import B）。你遇到的错误 attempted relative import with no known parent package 正是由于 B.py 在被 A.py 导入时，Python 无法识别其所属的父包，因此 ..fC 无从解析。
关键误区在于：相对导入（.., .）只适用于包内模块间的引用，且必须保证整个目录结构构成合法 Python 包，并通过正确的入口方式触发包上下文。 跨驱动器（如 C:\ → Z:\）本身不是障碍，但路径拼接与包发现机制必须协同工作。
✅ 正确做法是采用绝对导入 + 规范包结构：
- 确保每个文件夹都是合法包：在 fB 和 fC 目录下分别创建空文件 __init__.py（即使内容为空，也标志着该目录可被识别为包）；
- 统一项目根目录并加入 sys.path：在 A.py 开头，将 Z 驱动器上包含 fB 和 fC 的共同父目录添加到 sys.path（例如 Z:\project_root）；
- 使用绝对导入语法：在 A.py 中直接 from fB.B import some_func，并在 B.py 中改为 from fC.C import func（去掉 ..，因 fB 和 fC 是同级包）。
示例结构（推荐组织方式）：
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
立即学习“Python免费学习笔记（深入）”；
Z:\project_root/
├── __init__.py # 可选，但建议添加
├── fB/
│ ├── __init__.py # 必须存在
│ └── B.py # 内容：from fC.C import func
└── fC/
├── __init__.py # 必须存在
└── C.py # 定义 def func(): ...A.py（位于 C:\work\A.py）内容：
import sys # 将 Z:\project_root 加入 Python 模块搜索路径 sys.path.insert(0, r'Z:\project_root') # 现在可安全进行绝对导入 from fB.B import func_from_B # 或直接 from fB import B
⚠️ 注意事项：
- ❌ 避免在模块中动态修改 sys.path（如 sys.path.append(...)），这会降低可维护性且易引发路径冲突；
- ❌ 不要依赖相对导入跨驱动器或跨项目边界——它本质是设计用于单一包内部，而非任意路径跳转；
- ✅ 推荐将 Z:\project_root 设为虚拟环境的 PYTHONPATH 或通过 .pth 文件管理，比硬编码 sys.path 更健壮；
- ✅ 若需频繁跨位置复用代码，应考虑将 fB/fC 打包发布为可安装包（pip install -e .），从根本上解决路径依赖。
总结：跨文件夹导入并非“不可能”，而是需要遵循 Python 的包语义——以 __init__.py 奠定包基础，用绝对导入明确依赖关系，并通过 sys.path 或环境变量统一模块发现入口。抛弃相对导入的“捷径思维”，转向结构化、可复用的包设计，才是长期可维护的解决方案。
