不能。pkgutil.iter_modules()仅遍历指定包的直接子模块和子包，不递归进入子包内部；需手动判断ispkg并递归调用自身才能获取嵌套子模块。
pkgutil.iter_modules() 能否直接遍历嵌套子包？
不能。pkgutil.iter_modules() 默认只扫描指定包的**直接子目录/子模块**，不会递归进入子包内部。比如 myproject.utils 下有 myproject.utils.network 和 myproject.utils.date，调用 iter_modules(myproject.utils.__path__) 只会返回 network 和 date 这两个子包名，但不会自动展开它们各自的模块（如 network/client.py、network/server.py）。
常见错误现象：代码跑完没报错，但实际只加载了第一层，深层模块被跳过。
- 必须手动对每个发现的子包再次调用
iter_modules()，形成递归逻辑 - 注意判断是否为包：检查
is_pkg字段，值为True才代表是子包（含__init__.py），才需要继续遍历 - 避免无限递归：确保只处理当前包路径下的子项，不向上或跨包扫描
如何安全地 import 每个发现的模块？
拿到 ModuleInfo 后，不能直接用 importlib.import_module(name) —— 因为 name 是相对名（如 "network"），必须拼出完整模块路径（如 "myproject.utils.network"）。
使用场景：动态插件系统、测试用例自动收集、配置驱动的模块注册。
立即学习“Python免费学习笔记（深入）”；
- 构造完整模块名：用
f"{parent_package}.{info.name}"，其中parent_package是起始包的字符串名（如"myproject.utils"），不是模块对象 - 捕获
ImportError：子模块可能依赖未安装的库，或存在语法错误，需单独处理，避免一个失败中断全部加载 - 不建议用
exec或compile加载源码——绕过 Python 的导入缓存和符号解析，易引发重复初始化或命名冲突
为什么 pkgutil 不推荐用于生产环境的模块发现？
因为 pkgutil 本质是基于文件系统路径扫描，它无法识别 namespace package（PEP 420）、编辑器未保存的临时文件、zipimport 加载的包，也不感知 sys.meta_path 上自定义的 finder。
性能与兼容性影响：
- 每次调用都触发一次
os.listdir()和文件属性检查，在大型包中明显变慢 - Python 3.12+ 中部分行为更严格，对缺失
__init__.py的目录不再视为包（除非是 namespace package） - 若包通过
setuptools的find_packages()构建，但发布时未包含某些子目录，pkgutil仍会尝试扫描，导致误报
替代方案：importlib.metadata.entry_points() 更可靠吗？
不适用于“遍历包内所有模块”这个需求。它只读取 entry_points 配置（如 [console_scripts]），属于显式声明机制，和目录结构无关。
真正更稳的替代方式是结合 importlib.util.spec_from_file_location() + pathlib.Path.rglob("*.py")，但要注意：
- 过滤掉
__init__.py和测试文件（如*_test.py）需额外逻辑 - 路径转模块名需小心处理：把
/path/to/pkg/sub/thing.py映射为pkg.sub.thing，必须确保路径在sys.path或已加入sys.modules - 这种纯路径扫描绕过了 Python 导入系统的层级约束，容易加载到本不该被访问的私有模块（如
_internal.py）
真正复杂的地方在于：没有银弹。你要的是“所有模块”，但 Python 里“模块”的定义本身就依赖于导入上下文；一个 .py 文件是不是模块，取决于它有没有被 import 语句引用、有没有出现在 sys.path、有没有被 finder 接管。所以任何遍历方案都得先明确边界——是按磁盘结构？还是按运行时已知的包层级？这点经常被忽略。
