virtualenvwrapper不是提升python运行速度，而是极大降低环境管理的上下文切换成本；它通过workon等命令实现一键激活、mkvirtualenv按当前python版本创建、rmvirtualenv直接删除等自动化操作，避免手动cd/source和路径记忆。
virtualenvwrapper 不是“让 Python 更快”，而是把环境管理这件事从「每次都要 cd、source、记路径、怕搞错」变成「一个词就切过去」。它解决的不是运行时性能，而是开发者每天重复十几次的上下文切换成本。
workon 命令为什么比手动 activate 快得多
不用再找 venv/Scripts/activate.bat（Windows）或 venv/bin/activate（macOS/Linux），也不用记住每个项目的绝对路径。workon 直接按名字激活，背后自动定位到 WORKON_HOME 下对应目录。
- 手动方式：每次进项目都得
cd /path/to/project && source venv/bin/activate -
workon方式：任意目录下直接workon myproject，1 秒完成 - 如果当前 shell 没加载
virtualenvwrapper.sh，workon会报错command not found，这不是命令不存在，而是初始化没生效
mkvirtualenv 创建环境时默认继承当前 Python 版本
执行 mkvirtualenv myapp 时，它不会硬编码用系统默认 Python，而是优先使用你当前 shell 中的 python 可执行文件路径（由 VIRTUALENVWRAPPER_PYTHON 控制）。这点在多版本共存时特别关键。
pain-to-pip-package
下载
完整流程：Reddit 痛点扫描 → 聚类 → 构建 pip 可安装的 CLI 工具 → 推送到 GitHub。使用此模式已交付 5 款工具，经验证 343 条痛点。
- 如果你用
pyenv切到了3.11.9，mkvirtualenv默认就用这个版本建环境 - 想显式指定？加
-p参数：mkvirtualenv -p /usr/bin/python3.9 myapp - Windows 用户装的是
virtualenvwrapper-win，不认VIRTUALENVWRAPPER_PYTHON，它只认系统 PATH 里的第一个python.exe
rmvirtualenv 删除环境前不会二次确认
rmvirtualenv myapp 是不可逆操作，直接删整个目录——它不走 pip uninstall，也不留备份。容易误删，尤其当环境名缩写冲突时（比如 rmvirtualenv api 可能删掉 api-server）。
- 建议养成加
--help的习惯：rmvirtualenv --help看是否支持 dry-run（实际不支持，但至少确认命令意图） - 更安全的做法是先用
lsvirtualenv列出所有环境，复制全名再删 - 删除后
workon myapp会报错ERROR: virtualenv 'myapp' does not exist，这是正常反馈，不是崩溃
Windows 下 virtualenvwrapper-win 的路径陷阱
它默认把环境存在 %USERPROFILE%Envs，但如果你设置了 WORKON_HOME，必须用正斜杠或双反斜杠，否则 workon 找不到环境。
- 错误写法：
WORKON_HOME=C:myenvs→workon启动失败 - 正确写法：
WORKON_HOME=C:/myenvs或WORKON_HOME=C:\myenvs - 设置完要重启终端，或在当前 cmd 中执行
set WORKON_HOME=C:/myenvs（仅本次生效） - 验证是否生效：
echo %WORKON_HOME%（Windows）或echo $WORKON_HOME（Linux/macOS）
deactivate 能退出 workon 却忘了它只对当前 shell 有效。这些细节不写进日常操作流，就会反复消耗注意力。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
