python多版本共存依赖path与shebang协同，系统仅识别path首个python；pyenv通过shims动态路由版本，虚拟环境绑定创建时的绝对路径，windows需禁用py启动器以统一管理。
Python 多版本共存靠的是 PATH 和 shebang 的配合
系统本身不“知道”你装了几个 Python，它只认 PATH 里第一个匹配的 python 命令。多版本能切换，本质是让不同路径下的 python3.9、python3.11 等二进制文件被优先找到，或者靠脚本头部的 #!/usr/bin/env python3.10 显式指定解释器。
常见错误现象：运行 python --version 和 which python 结果对不上；虚拟环境中 python 指向宿主系统 Python；用 pyenv 切换后 pip 仍装到老版本。
- Mac/linux 下默认不改
/usr/bin/python，系统级 Python 一般只读，别硬链接覆盖 -
pyenv是通过在PATH最前插入~/.pyenv/shims实现拦截，所有python/pip调用先过 shims 脚本判断当前版本 - Windows 用户直接依赖
py启动器（py -3.9），它会查注册表和PATH，不走 shims 机制
pyenv 的 shims 不是符号链接，而是生成的 shell 脚本
很多人以为 pyenv global 3.11.5 就是把 python 指向某个二进制，其实不是——~/.pyenv/shims/python 是个几十行的 bash 脚本，每次执行时动态解析当前目录的 .python-version 或环境变量 PYENV_VERSION，再调用对应版本的真正二进制。
这导致两个关键行为：shims 启动略慢（毫秒级）、无法被某些静态分析工具识别真实解释器路径。
立即学习“Python免费学习笔记（深入）”；
- 不要手动修改
~/.pyenv/shims/python，它会被pyenv rehash覆盖 - 如果某工具（如 VS Code 的 Python 扩展）卡在“找不到 interpreter”，优先检查它是否读取了
pyenv which python而非which python -
pyenv local写入的是.python-version文件，内容只是版本号（如3.10.12），不是完整路径
venv 创建时用的是绝对路径，和当前 pyenv 版本强绑定
python -m venv myenv 这条命令中，python 是哪个版本，生成的 myenv/bin/python 就硬编码指向那个版本的解释器路径。哪怕之后用 pyenv global 切到别的版本，这个虚拟环境也不会变。
典型问题：在 3.9 下建的 venv，升级项目要求 3.11，直接切 pyenv 版本不会让旧 venv 自动迁移——它还是跑在 3.9 上。
- 确认 venv 解释器真实版本：运行
myenv/bin/python -c "import sys; print(sys.executable)" - 不要用
cp -r复制 venv 目录来“迁移到新版本”，依赖可能不兼容 - 安全做法是删掉旧 venv，切换 pyenv 版本后再重新
python -m venv
Windows 上 py -3.x 启动器不读 .python-version
Windows 自带的 py 启动器（来自 Python Launcher）完全独立于 pyenv，它只查注册表、PATH 和命令行参数（如 py -3.11），不会看当前目录有没有 .python-version。
这意味着你在 Windows 用 pyenv 设置 pyenv local 3.11.8，然后敲 py，大概率还是启动注册表里默认的那个版本。
- Windows 用户若想统一管理，建议禁用系统
py启动器，全程用pyenv+pyenv-win（注意它是独立实现，shims 逻辑和 Linux 版不一致） -
py -0p可列出所有已注册的 Python，但注册动作需手动运行安装包或pyenv install后的注册步骤 - VS Code 在 Windows 上默认调用
py，要让它识别 pyenv，得在设置里显式填python.defaultInterpreterPath为~.pyenvpyenv-winshimspython.bat
真正的难点不在装几个版本，而在于每个工具链（shell、编辑器、CI 脚本、Dockerfile）各自怎么找 Python——它们根本不共享同一套“当前版本”概念。