pip 报无法导入 get_runnable_pip，检查新旧文件混装

虚拟环境创建完成，运行 pip 却报 ImportError: cannot import name 'get_runnable_pip' from 'pip._internal.utils.misc'。若此前用 --ignore-installed 把 pip 26.2 覆盖成26.1.2，要检查目录里是否混进了两个版本的内部模块。

一个明确形态是调用栈从26.1.2的 main_parser 进入 pip._internal.build_env，实际加载的却是26.2残留的 build_env/__init__.py 和 installer.py。新 installer 从 utils.misc 导入 get_runnable_pip，而26.1.2的 misc 没有这个函数，于是 pip 连命令解析都无法完成。

不是 virtualenv 只能搭配某一个 pip

pip 26.1.2正式发行物使用单文件 build_env.py；26.2.1已经改成 build_env 包目录，并把 get_runnable_pip 移到 utils.misc。正常替换需要清理旧发行物拥有的文件。--ignore-installed 的含义是忽略已安装状态并覆盖，并不执行一次完整、可靠的卸载替换。

所以，更换 virtualenv 的版本后“碰巧恢复”，不能证明 virtualenv 与所有旧 pip 都不兼容。真正需要去掉的是产生混合安装的步骤，包括构建脚本、requirements里的 pip 固定项，以及 PIP_IGNORE_INSTALLED 环境变量。

先保存创建日志和依赖清单。检查完整调用栈所指文件，不要只根据一个 dist-info 目录或版本字符串推断所有源码都来自同一版。报错若来自另一套系统 Python，仍应先确认解释器归属；这里讨论的是同一个环境内的残留文件。

在新环境里恢复一套完整工具链

不要把新版 utils.misc 单文件复制进旧 pip，也不要随意删除某个 build_env 目录去试。内部模块并不是独立兼容接口，修好一次导入仍可能留下更多版本错配。

环境由 virtualenv、tox、uv 或 CI 管理时，优先修正它的创建与安装流程，再在全新位置创建环境。下面仅是标准 venv 的另一种重建示例，要求指定解释器支持 venv/ensurepip，且新路径尚不存在：

if [ -e .venv-rebuilt ] || [ -L .venv-rebuilt ]; then
    printf '%s\n' '.venv-rebuilt already exists' >&2
    exit 1
fi
/path/to/python -m venv .venv-rebuilt

替换解释器路径，确认创建成功后，再用新环境的 Python 按项目认可的依赖清单安装。不要再次用带 --ignore-installed 的旧脚本覆盖 pip。系统管理的 Python 应遵守其安装约定，不在系统目录强行修补；Windows也应采用实际管理工具对应的路径与流程。

旧环境可能已经无法运行 pip freeze，项目原有锁文件、构建清单和部署记录更重要。保留旧目录作证据，不能把业务代码或数据混在环境中一起删除。

切换前确认 pip 的模块与入口都来自新环境，原来的命令解析、依赖安装和应用功能恢复。pip check只检查声明的依赖关系，不能证明已安装文件没有残留混合。新的安装正常后，再把IDE、服务及CI入口统一切过去；环境路径改变也会影响已有脚本的解释器入口。