pkg_resources被弃用因其设计定位是构建期工具而非运行时组件，Python 3.12起默认不安装setuptools导致ModuleNotFoundError，推荐改用importlib.metadata和importlib.resources。

pkg_resources 性能差、被弃用，不是因为它“写得烂”，而是它从设计上就不是为运行时服务的——它本质是构建期工具链的一部分，却被长期当运行时 API 用。

为什么 pkg_resources 启动慢、内存高？

它在首次 import 时会扫描整个 sys.path，逐个解析 EGG-INFO 和 dist-info 目录，重建包依赖图；还要处理 .pth 文件、命名空间包、开发模式（pip install -e）等边界情况。这个过程是 O(n) 且不可缓存的，每次导入都可能重复执行。

python学习

Python 编程学习助手 skill，面向零基础用户。 当用户表达以下意图时触发： - 学习 Python 基础概念（变量、数据类型、循环、函数、类等） - 请求 Python 练习题或测验 - 请求审查或调试 Python 代码 - 请求 Python 项目实战指导（爬虫、数据分析、Web 开发等入门项目） - 泛化表述如"教我 Python""我想学编程""Python 怎么写""帮我学 Python" 此 skill

下载

pkg_resources 被弃用的核心原因不是性能，而是职责错位

• 它属于 setuptools，而 setuptools 是构建/发布工具，不是 Python 运行环境的一部分
• Python 标准库从 3.8 起提供 importlib.metadata，3.9 起提供 importlib.resources.files()，功能覆盖全部常用场景，且无额外依赖
• Python 3.12 默认不安装 setuptools，import pkg_resources 直接抛 ModuleNotFoundError，不再容忍隐式依赖

迁移到 importlib.metadata 后的真实变化

替换 pkg_resources.get_distribution("requests").version → importlib.metadata.version("requests")，不只是函数名换掉：

• 前者返回一个重量级对象，带 .location、.requires、.parsed_version 等属性；后者直接返回字符串，需要版本比较时才调用 packaging.version.parse()
• 前者扫描所有路径找包；后者只查已安装的 dist-info 元数据目录，启动快 3–5 倍
• 前者在 PyInstaller 打包后常因路径失效崩溃；后者天然支持 zipimport、冻结二进制和命名空间包

真正麻烦的从来不是改一行代码，而是那些靠 __file__ 拼路径、用 os.path.dirname(__file__) 加载资源的逻辑——它们在 importlib.resources.files() 下根本跑不通。