模块边界不清导致循环引用、命名空间污染、相对导入失败及测试污染，应通过抽离公共模块、运行时导入、显式导入、绝对导入和规范测试路径来解决。
模块导入时循环引用报错 ImportError 或 ModuleNotFoundError
模块边界不清最直接的后果，就是两个模块互相 import，Python 在解析时卡住。比如 a.py 里写了 from b import func_b，而 b.py 又写了 from a import func_a，执行 a.py 就可能触发 ImportError: cannot import name 'func_b' from partially initialized module 'b'。
这不是语法错误，是 Python 导入机制的必然结果：模块加载是单向、顺序、一次性的。一旦某个模块在初始化中途被另一个模块试图读取未定义的属性，就崩。
- 优先把共享逻辑抽到第三个模块（比如
common.py或utils.py），让a和b都只单向依赖它 - 实在绕不开双向调用，改用运行时导入：
def some_func(): from b import func_b; return func_b()，把import放进函数体里，避开模块级加载阶段 - 检查
__init__.py是否偷偷触发了跨模块导入——很多人在这里写from .submodule import *，无意中拉起整条依赖链
from module import * 污染命名空间引发的覆盖和调试困难
边界不清常表现为“图省事”式导入。from requests import * 看似方便，但会把 get、post、Session 全塞进当前作用域，一旦本地变量也叫 get，就静默覆盖；更糟的是，别人读代码时根本看不出 get 是来自 requests 还是本地定义。
这种写法还会让 IDE 和静态检查工具失效，mypy 或 pylint 基本无法推断类型，git blame 也难定位来源。
立即学习“Python免费学习笔记（深入）”；
本文档主要讲述的是Python之模块学习；python是由一系列的模块组成的，每个模块就是一个py为后缀的文件，同时模块也是一个命名空间，从而避免了变量名称冲突的问题。模块我们就可以理解为lib库，如果需要使用某个模块中的函数或对象，则要导入这个模块才可以使用，除了系统默认的模块（内置函数）不需要导入外。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
- 永远用
import requests或明确的from requests import get, post - 如果要批量导入，只在
__init__.py中控制导出项，通过__all__ = ["get", "post"]显式声明，而不是靠*猜 -
pylint的W0401警告就是专抓这个的，别 suppress
包内相对导入写错路径导致 ImportError: attempted relative import with no known parent package
这是新手在组织多层包时最常撞的墙。比如项目结构是 myproject/ ├── __init__.py ├── core/ │ ├── __init__.py │ └── db.py └── api/ ├── __init__.py └── handler.py，想在 handler.py 里导入 core.db，写成 from ..core import db 就会报错——因为 Python 不知道当前文件是以包方式运行的。
根本原因：相对导入只在模块作为包的一部分被导入时才有效；直接 python api/handler.py 运行，__name__ 是 __main__，不是 api.handler，Python 拒绝解析 ..。
- 确保用
python -m myproject.api.handler启动，而不是python api/handler.py - 在
handler.py顶部加个保护：if __name__ == "__main__": from ..core import db不行，必须把导入移到函数里或改用绝对导入 - 更稳妥的做法：统一用绝对导入，比如
from myproject.core import db，并把myproject加进PYTHONPATH或安装为可编辑包（pip install -e .）
测试模块误用生产模块路径导致覆盖率失真和环境污染
边界不清还藏在测试里。常见做法是把 tests/ 和 src/ 平级放，然后在 tests/test_db.py 里写 from db import Database —— 表面跑得通，实际可能导入的是当前目录下的 db.py（比如你临时写的脚本），而非 src/db.py。结果测试通过了，上线却挂。
更隐蔽的问题是：测试模块修改了生产模块里的全局状态（比如 patch 了 time.time 却没还原），下一个测试用例就拿到脏数据。
- 测试入口统一放在项目根目录下，用
pytest tests/并确保src/在sys.path最前（可通过pyproject.toml的[tool.pytest.ini_options]配置pythonpath = ["src"]） - 避免在测试中直接修改生产模块的模块级变量；要用
unittest.mock.patch且加autouse=True或显式stop() - CI 里加一条检查：
python -c "import db; print(db.__file__)"，确认导入路径符合预期
模块边界的本质不是文件怎么切，而是“谁该知道什么”。一个函数是否需要看到另一个模块的实现细节，比路径怎么写更重要。很多问题其实出现在重构前没人敢动的 __init__.py 和到处乱飞的 import * 里。
