命名空间包的核心特点是无需__init__.py文件，支持将同名包分散在多个物理路径中并由python自动合并为一个逻辑包。它可解耦发布节奏、避免安装冲突、支持跨团队协作与插件扩展，要求所有子包均不包含__init__.py以确保隐式命名空间行为生效。
因为命名空间包能解耦发布节奏、避免安装冲突、支持跨团队协作，而不是靠“把所有代码塞进一个仓库”来维持一致性。
多个团队独立发布同一命名空间下的子包
当 acme 是组织级命名空间时，acme.sql 和 acme.auth 可由不同团队分别开发、测试、打包、上传 PyPI，互不干扰。只要它们都声明了 namespace_packages=['acme'] 或使用隐式结构（无 __init__.py），安装后 Python 就会自动合并 acme 的 __path__。
- 显式声明需在
setup.py中写namespace_packages=['acme']；Python 3.3+ 更推荐隐式方式（直接删掉所有acme/__init__.py） - 如果某个子包误带了
acme/__init__.py，它会变成普通包，阻断其他同名目录的合并 —— 这是常见静默失败点 -
pip install acme-sql acme-auth后，import acme.sql和import acme.auth都能工作，且acme.__path__包含两个路径
插件或扩展模块需要挂载到已有命名空间
比如你维护一个核心库 mlxtk，希望第三方开发者能提供 mlxtk.backend.cuda 或 mlxtk.backend.metal，但你不希望他们 fork 你的主 repo 或等你发版才集成。
- 第三方只需创建目录
mlxtk/backend/cuda/__init__.py并打包上传，用户pip install mlxtk-backend-cuda即可生效 - 关键前提是：你的主包
mlxtk必须是命名空间包（即不含mlxtk/__init__.py），否则第三方模块无法注入 - 运行时可通过
pkgutil.iter_modules(mlxtk.__path__)动态发现所有已安装的mlxtk.*子模块
隐式命名空间包比显式声明更可靠
Python 3.3+ 默认支持无 __init__.py 的隐式命名空间包，它不依赖 setup.py 中的 namespace_packages 参数，兼容性更好，也更少出错。
- 只要
sys.path中存在多个同名目录（如/venv/lib/python3.x/site-packages/acme_sql-1.0.0-py3.x.egg/acme/和/src/acme_auth/acme/），导入时就会自动合并 -
setuptools在构建时若检测到空__init__.py，可能仍按普通包处理，导致意外覆盖 —— 直接删掉最稳妥 - 用
python -c "import acme; print(acme.__path__)"验证是否成功合并，输出应为包含多个路径的列表
真正容易被忽略的是：命名空间包没有 __file__ 属性，且不能直接放顶层模块（比如 acme/utils.py 是非法的，必须放在子包里）。这意味着所有逻辑必须下沉到 acme.* 的子路径下，设计初期就得想清楚层级。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
