Python 3.12 移除 imp、distutils 等模块：一次主动的“电池清理”，而非意外
如果你在升级到 Python 3.12 后，发现 imp 或 distutils 这些老朋友不见了，请先别急着报 bug。这并非意外，而是一次蓄谋已久的“大扫除”——Python 社区依据 PEP 594，主动将这些被标记为“已死亡电池”的模块从标准库中彻底移除了。
PEP 594 定义了哪些模块被归为 “dead batteries”
那么，究竟哪些模块被列入了这份“清理名单”？PEP 594 给出了明确标准：那些长期无人维护、功能已被更好方案取代、存在安全隐患，或者使用率已经低到可以忽略不计的模块，就被定义为“dead batteries”。这次移除不是心血来潮，而是多年弃用警告后的最终执行。被移除的核心成员包括：
imp：它的全部功能早已被更强大、更安全的importlib模块覆盖。尤其是像imp.load_source()这样的接口，本身就存在安全风险，淘汰是必然。distutils：这个老牌的构建工具，以其混乱的内部逻辑和不一致的 API 著称，早已被setuptools全面取代。顺带一提，依赖它的numpy.distutils也随之失效。- 一批“古董”模块：如
aifc、audioop、cgi、imghdr等。它们的应用场景在现代开发中已大幅萎缩，社区也提供了更现代、更安全的替代品。例如，cgi的部分功能现在完全可以用http.server等模块更好地实现。
为什么不能 pip install distutils 或 imp
遇到模块缺失，很多开发者的第一反应是尝试用 pip 安装回来。但这次，此路不通。原因在于，这根本不是包管理问题，而是语言层面的设计事实：
- 首先，PyPI 上压根就不存在合法的
distutils或imp包。因为在 CPython 3.12 的源码树里，这些模块的 .py 文件已经被物理删除，连存根文件都没留下。 - 你可能会发现，安装
setuptools后，一些原本属于distutils的命令（比如build_ext）又能用了。但这其实是setuptools在运行时动态注册的兼容性命令，它并没有、也不会重新提供distutils这个模块本身。 - 所以，任何试图
import distutils或import imp的操作，都会直接触发ModuleNotFoundError，没有任何取巧的绕过方法。
迁移时最常踩的三个坑
表面上看，迁移似乎很简单：把 import 语句换掉就行。但实际操作过就知道，真正的麻烦往往藏在代码的深层耦合里。以下几个坑，稍不注意就会踩中：
立即学习“Python免费学习笔记（深入）”；
- 坑一：版本比较逻辑的陷阱。 简单地把
from distutils替换成from setuptools可能不够。如果你的代码里用到了distutils.version.LooseVersion来做版本比较，必须换成packaging.version.parse()，否则版本比较的逻辑可能会出错。 - 坑二：自定义构建类的继承链断裂。 在
setup.py中，如果你有继承自distutils.command.build_ext的自定义类，必须将其父类明确改为setuptools.command.build_ext.build_ext。否则，在 Python 3.12 环境下，类构造会直接失败。 - 坑三：科学计算包的构建依赖。 对于那些使用了
numpy.distutils的旧项目（尤其是一些带 C 扩展的科学计算包），仅仅升级setuptools是没用的。必须将numpy升级到 1.26 或更高版本，并考虑将构建系统迁移到pybind11或meson。
话说回来，最棘手的从来不是那些立刻抛出的错误，而是那些“静默的差异”。举个例子，distutils.dir_util.copy_tree() 处理符号链接的方式，和 shutil.copytree(..., symlinks=True) 并不完全等价。这种细微的行为差异不会在测试时报错，却可能在部署到生产环境时突然暴露，造成难以排查的问题。因此，迁移后的全面测试，至关重要。
