python 禁止在非包（non-package）脚本中使用相对导入，核心目的是强制开发者遵循标准化的项目结构——即通过正确打包（packaging）来提升可维护性、可移植性与工具链兼容性。
python 禁止在非包（non-package）脚本中使用相对导入，核心目的是强制开发者遵循标准化的项目结构——即通过正确打包（packaging）来提升可维护性、可移植性与工具链兼容性。
在 Python 的模块系统设计中，相对导入（如 from ..modules import module1）并非技术上不可实现，而是一项有意为之的架构约束。其根本逻辑在于：相对导入语义依赖于明确的包层级关系，而这种层级只有在 Python 将一个目录识别为“包”（即该目录下存在 __init__.py 且被作为包加载）时才成立。当直接运行一个独立 .py 文件（例如 scripts/script1.py），Python 解释器将其视为 __main__ 模块，而非包内子模块——此时 . 和 .. 无明确锚点，相对路径失去上下文依据，故语法被显式禁止。
这看似带来短期不便，实则指向更健壮的工程实践。以你描述的项目结构为例：
my_project/
├── modules/
│ ├── __init__.py
│ ├── module1.py
│ └── module2.py
└── scripts/
├── script1.py # ❌ 直接运行 → 不是包成员 → 无法用 from ..modules import ...
└── script2.py若强行用 sys.path.append(...) “打补丁”，虽能临时绕过限制，却会引发隐式依赖、路径脆弱、跨环境失效等问题。而官方推荐的解法是：将整个项目升级为符合 PEP 517/518 标准的可安装包。
✅ 正确做法：重构为标准包结构
重组织目录，添加 pyproject.toml，使项目本身成为一个可安装包：
my_project/ ├── pyproject.toml # 声明元数据与入口点 ├── my_project/ # 包名（与项目名一致） │ ├── __init__.py │ ├── modules/ │ │ ├── __init__.py │ │ ├── module1.py │ │ └── module2.py │ ├── script1.py # ✅ 现在是 my_project.script1，可安全使用 from ..modules import module1 │ └── script2.py
在 pyproject.toml 中声明命令行入口：
立即学习“Python免费学习笔记（深入）”；
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
[project] name = "my-project" version = "0.1.0" [project.scripts] script1 = "my_project.script1:main" script2 = "my_project.script2:main"
随后执行：
pip install -e . # 开发模式安装
即可全局调用 script1 和 script2 命令，且所有模块导入（包括相对导入）均自然生效。
? 关键优势不止于导入便利：
- ✅ 安装后自动配置
PATH，脚本开箱即用； - ✅ 支持
pytest等工具无缝发现测试； - ✅ 兼容 CI/CD、多版本测试（如
tox）、IDE（PyCharm 自动识别源根）； - ✅ 未来扩展为 PyPI 包零成本迁移。
⚠️ 注意事项：
- 切勿在未安装包的情况下仍用
python scripts/script1.py方式运行——这会再次退化为__main__上下文，相对导入仍报错； - 所有脚本应通过
python -m my_project.script1或已安装的 CLI 命令调用，确保其作为包内模块加载； - 若暂不想打包，临时替代方案是使用绝对导入（如
from my_project.modules import module1），但需确保my_project在sys.path中——这仍是权宜之计，不应成为长期策略。
归根结底，Python 用“禁止相对导入”这一明确的语法错误，温柔而坚定地引导开发者走向更可持续的工程范式：每一个值得组织多个文件的项目，都值得被认真打包。这不是限制，而是对代码生命力的投资。
