venv适合只需隔离环境、不需依赖锁定的轻量场景，创建快、无额外依赖；pipenv适合需精确复现依赖的协作项目，但2026年仍存在解析卡死、调试困难等稳定性问题。
venv 更适合“只想要个干净环境”的场景，pipenv 更适合“需要锁定依赖、多人协作”的项目——但它的稳定性问题在 2026 年仍未彻底解决。
什么时候该用 venv？
你只需要隔离 Python 解释器和包，不关心依赖版本是否可复现，也不需要区分开发/生产依赖。
- 创建快：
python -m venv .venv几秒完成，无额外安装步骤 - 启动轻：激活后就是原生
pip和python，没有抽象层干扰 - 导出依赖靠自己：
pip freeze > requirements.txt后，别人用pip install -r requirements.txt还原，但无法保证两次安装结果一致（比如pip install requests可能装 2.31.0 或 2.32.0） - 常见踩坑：Windows PowerShell 默认禁止执行
Activate.ps1，得先运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser；macOS/Linux 忘记source而直接敲.venv/bin/activate会报错“command not found”
什么时候该用 pipenv？
你希望一个命令搞定环境创建 + 依赖安装 + 版本锁定 + 开发/生产分离，且团队成员能一键还原完全相同的环境。
Python Matplotlib Chinese Font
下载
使用 font_manager.addfont() 添加中文字体文件，设置 rcParams['font.family']，并禁用 unicode_minus，使 matplotlib 显示中文。
- 它自动生成
Pipfile（TOML 格式，比requirements.txt更结构化）和Pipfile.lock（含所有依赖的哈希值和精确版本） -
pipenv install --dev pytest black会把测试/格式化工具单独记在[dev-packages]下，部署时用pipenv install --ignore-pipfile就能跳过它们 - 但实际使用中容易卡住：
pipenv install内部会反复调用pip install直到解析收敛，遇到复杂依赖（比如同时要tensorflow和pytorch）可能无限重试或静默失败 - 另一个现实问题：
pipenv graph输出可读性差，调试依赖冲突时不如直接看pipdeptree；而且它不支持全局镜像源配置，国内用户每个项目都得手动设PIPENV_PYPI_MIRROR
venv 和 pipenv 的兼容性差异
两者底层都基于 venv 创建环境目录，但 pipenv 把这个过程封装掉了——你无法用 pipenv 指向一个已存在的 .venv 目录，也不能在已有 venv 中直接启用 Pipfile。
-
venv环境可被任何工具识别：PyCharm、VS Code、uv、甚至手动python /path/to/.venv/bin/python都能用 -
pipenv环境路径藏在~/.local/share/virtualenvs/（Linux/macOS）或%LOCALAPPDATA%\VirtualEnvs\（Windows），项目里只留Pipfile，导致跨机器迁移时容易漏掉 lock 文件或环境本身 - 如果你用 CI/CD，
venv + requirements.txt更易调试：出错了直接进容器pip list就能看到当前装了啥；而pipenv install失败时，日志里全是嵌套的 subprocess 输出，定位具体哪一行依赖崩了很难
真正关键的不是“哪个好用”，而是“你是否愿意为锁文件多等 2 分钟，以及能否接受 pipenv 在某些依赖组合下静默降级或卡死”。如果项目要长期维护、上生产，pipenv 的 Pipfile.lock 是刚需；如果只是跑个脚本验证想法，venv 多敲两行 pip freeze 更省心。现在（2026 年），很多团队已转向 uv 或 poetry，因为它们解决了 pipenv 的性能和可靠性短板，但 venv 仍是理解所有工具的基础——毕竟连 pipenv 自己，也是用 venv 创建底层环境的。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
