venv创建时pip来自ensurepip预置包而非全局pip，其版本由Python安装目录中ensurepip模块决定；升级单个venv的pip不影响新环境，需修改ensurepip.__init__.py及_bundled/中的whl文件才能统一源头版本。
venv 创建时 pip 来自 ensurepip 捆绑包，不是当前全局 pip
新建 venv 时，Python 并不会复制你当前终端里 pip --version 显示的那个 pip，而是调用内置的 ensurepip 模块，从 Python 安装目录里自带的 _bundled/ 文件夹中解压预置版本。这个预置 pip 版本通常滞后于 PyPI 上的最新版——比如 Python 3.12.6 自带的可能是 pip 24.2，而当前最新已是 pip 25.0.1。
升级 venv 中的 pip 不等于升级系统 Python 的 ensurepip
你在激活虚拟环境后执行 python -m pip install --upgrade pip，确实能更新该 venv 里的 pip，但只影响这一个环境；下次再用 python -m venv newenv，新环境仍会回到旧版本。真正影响所有新 venv 的，是修改 Python 安装目录下的 ensurepip.__init__.py 中的 _PIP_VERSION 和对应 whl 文件。
- Windows 路径示例：
C:\Program Files\Python312\Lib\ensurepip\__init__.py - macOS/Linux 路径示例：
/usr/local/lib/python3.12/ensurepip/__init__.py - 必须同步把下载好的
pip-X.Y.Z-py3-none-any.whl放进同目录下的_bundled/子目录 - 修改后需重新运行
python -m venv才生效，已有 venv 不受影响
pyenv 或系统多 Python 版本时，ensurepip 绑定更隐蔽
如果你用 pyenv 管理多个 Python 版本，每个版本都有独立的 ensurepip，升级逻辑一样，但路径分散在 ~/.pyenv/versions/3.12.6/lib/python3.12/ensurepip/ 这类位置。容易误以为“升级了全局 pip 就够了”，其实只是改了某个 shell session 里 pip 命令的软链指向，对 venv 初始化无任何作用。
验证方式很简单：创建新 venv 后不手动升级，直接运行 pip -V，看输出的路径是否指向 venv/Lib/site-packages/pip（说明是安装的）还是 venv/Lib/ensurepip/_bundled/（说明是解包的原始版本）——后者才是问题根源。
别依赖 pip install --upgrade pip 作为长期方案
每次新建 venv 都手动升级 pip，看似可行，实则埋下三类隐患：
- CI/CD 流水线中可能因网络或权限失败，导致构建中断
- 某些受限环境（如离线 Docker 构建）无法联网下载新 pip
- 不同人创建的 venv pip 版本不一致，引发协作时的不可复现行为
真正可控的做法，是统一源头：要么提前 patch ensurepip，要么用 uv venv 替代 venv（uv 默认使用最新 pip，且无需修改 Python 安装文件）。
