假设你的项目结构为：

 your_project/
├── fastreid/                  # 自定义包
│   ├── __init__.py
│   └── config/
│       ├── __init__.py
│       └── config.py
└── your_script.py             # 你的脚本

1. 在 config.py 中定义函数：

   # fastreid/config/config.py 
   def get_cfg(): 
       print("Config loaded!")

2. 在子包初始化文件中暴露函数：

   # fastreid/config/__init__.py 
   from .config import get_cfg

3. 在脚本中测试导入：

   # your_script.py 
   from fastreid.config import get_cfg 
   get_cfg() # 输出 "Config loaded!"

---

# 在 fastreid/config/__init__.py 文件中：

# 相对导入：从当前包（config子包）的 config 模块中导入指定对象
from .config import CfgNode, get_cfg, global_cfg, set_global_cfg, configurable

# 定义 __all__ 列表，明确声明对外暴露的公共接口
__all__ = [
    'CfgNode',
    'get_cfg',
    'global_cfg',
    'set_global_cfg',
    'configurable'
]

代码作用解释 🛠️

1. 相对导入 (from .config import ...)：

   • .config 表示从当前包（config子包） 的同级模块 config.py 导入对象
   • 例如：CfgNode 和 get_cfg 实际定义在 fastreid/config/config.py 文件中

2. __all__ 的作用：

   • 显式声明该模块对外公开的接口（公共API）
   • 当使用 from fastreid.config import * 时，只会导入 __all__ 中列出的对象
   • 避免暴露内部实现细节（如未列出的其他类/函数）

---

为什么这样设计？ 🤔

1. 封装性

• 通过 __all__ 明确暴露用户需要使用的核心功能（如 get_cfg），隐藏模块内部其他辅助类/函数
• 示例：用户只需知道 from fastreid.config import get_cfg，无需关心 CfgNode 的实现细节

2. 维护性

• 如果后续 config.py 新增内部函数（如 _internal_helper），但未加入 __all__，则外部代码无法通过 import * 意外引用它
• 减少因模块内部修改导致的外部代码兼容性问题

3. 导入便捷性

• 通过 __init__.py 的导入操作，用户可以直接从包顶层访问核心对象：

  Python

  # 用户代码示例 from fastreid.config import get_cfg # 直接调用，无需写 from fastreid.config.config import get_cfg cfg = get_cfg()

---

类比理解 🍎

想象一个工具箱（config子包）：

• config.py：工具箱内的所有工具（包括螺丝刀、锤子等）
• __init__.py：工具箱的展示窗口，只将常用工具（__all__ 列出的）放在窗口显眼位置
• 用户：只需打开工具箱（import fastreid.config），直接拿取展示窗口的工具，无需翻找内部抽屉

---

典型应用场景 🌟

当包需要提供简洁的API时，这种模式可以让用户：

1. 避免冗长的导入路径（如 from package.submodule.subsubmodule import func）
2. 清晰了解哪些是官方推荐使用的接口
3. 降低因误用内部代码导致的问题