Mac 下virtualenv pipenv venv conda 区别解读及 conda 安装 uwsgi 注意事项

原创已于 2026-04-10 14:32:13 修改 · 2.9k 阅读

5 ·

本内容遵循CC 4.0 BY-SA版权协议

标签

#python #virtualenv #conda

于 2022-04-14 11:19:09 首次发布

python 专栏收录该内容

32 篇文章

订阅专栏

一、核心概念：版本环境 vs 虚拟环境

初学者往往会将这两个概念混淆，但它们解决的是完全不同的问题。

版本环境（Python Version Environment）：
- 作用： 决定了你使用的是哪个版本的 Python 解释器（例如 Python 3.8 或 3.10）。
- 类比： 就像电脑里可以同时安装多个版本的 JDK，操作系统里也可以存在多个不同版本的 Python 解释器。它们各自占据不同的系统路径，提供最基础的全局运行环境。
虚拟环境（Virtual Environment）：
- 作用： 为了解决不同项目之间的“依赖包冲突”而诞生的隔离空间。它确保项目 A 和项目 B 即使依赖同一个包的不同版本，也能互不干扰。
- 两者的关系： 虚拟环境是寄生在版本环境之上的。你必须先有一个基础的 Python 解释器（版本），才能基于它创建一个个相互隔离的“房间”（虚拟环境）。

二、底层原理：虚拟环境是如何工作的？

理解虚拟环境的本质，就能明白为什么有时候它会“失效”。

只是快捷方式，不是完整拷贝： 使用 venv 或 virtualenv 创建的虚拟环境，并没有复制一个完整的 Python 解释器。它更像是在当前文件夹下创建了一个指向“全局原始解释器”的快捷方式。
隔离的只是包路径： 当你激活虚拟环境时，系统只是将第三方包的读取路径（site-packages）指向了当前虚拟环境的文件夹，而不是全局文件夹。最终执行代码的，依然是那个底层的原始解释器。

三、避坑指南：“纯代码包”与“可执行软件”的差异

在虚拟环境中使用 pip 安装依赖时，需要区分你安装的是什么：

普通依赖包（如 requests, numpy）：
- 它们只是代码集。在虚拟环境中运行时，会顺畅地从隔离的 site-packages 中加载，不会报错。
依赖底层环境的可执行软件包（如 uwsgi）：
- 这类软件不仅包含 Python 代码，还需要编译，并深度依赖 C 语言库和 Python 解释器的底层环境。
- 报错原因： 因为虚拟环境只是个“快捷方式”，当你用 pip 在虚拟环境中安装这类软件时，它可能会穿透虚拟环境，直接与底层的全局解释器产生交互，导致安装路径错乱（例如安装到了 Mac 的原生根目录下），最终在执行时因为版本不兼容或依赖缺失而报错。

四、终极解决方案：Conda vs venv / virtualenv

正是因为上述“可执行软件”在普通虚拟环境中容易出现底层依赖混乱，才凸显了 Conda 的强大。

特性	venv / virtualenv (通过 pip)	Conda
隔离级别	浅层隔离：只隔离第三方 Python 包 (`site-packages`)。	深层隔离：既隔离 Python 包，也隔离 Python 解释器版本和底层 C 库。
解释器状态	依赖系统已有的全局 Python 解释器（建立快捷方式）。	为每个环境下载并创建一个完全独立的 Python 解释器。
包管理范围	只能管理纯 Python 语言相关的依赖包。	跨语言的包环境管理器。既能管理 Python 包，也能处理非 Python 的底层依赖。
安装复杂软件 (如 uwsgi)	容易因底层解释器路径和 C 库依赖不匹配而报错。	推荐。`conda install uwsgi` 会将其底层依赖完好地封装在当前环境中，与系统环境彻底物理隔绝。

总结： 如果你的项目纯粹只用 Python 原生包，venv 足够轻量好用。但如果你需要安装像 uwsgi 这样涉及复杂底层编译和非 Python 依赖的软件，强烈建议使用 Conda。Conda 能够提供“解释器版本 + 依赖包 + 底层环境”的三位一体全封闭隔离，彻底杜绝环境污染。

五、核心避坑：虚拟环境与底层解释器的“版本错位”

在使用虚拟环境和可执行软件（如 uwsgi）时，极易发生一种隐蔽的报错，即解释器版本错位。

错误场景重现：

假设你基于系统全局的 Python 3.7 创建了一个虚拟环境，并在该环境内使用 pip 安装了 uwsgi 及其他依赖包。此时，所有的包都是基于 3.7 的底层特性和 C 库编译构建的。

然而，如果在实际部署或启动项目时，系统的环境变量或启动脚本不小心指向了外层全局的 Python 3.8 解释器来运行这个 uwsgi。
导致的结果：

Python 3.8 的解释器强行去加载和运行为 Python 3.7 编译的代码和底层依赖。这会引发严重的包版本冲突、C 语言 API 不兼容，最终直接报出底层代码错误或服务启动失败。
黄金原则：“谁创建，谁执行”

虚拟环境及其内部安装的软件，必须与其赖以生存的底层版本环境（解释器版本）保持绝对一致。

简而言之： 用哪个版本的 Python 创造了这个虚拟环境，就必须强制系统用该版本的 Python 来运行 uwsgi。这也是前文强调使用 Conda 的原因，Conda 会将解释器本身锁定在环境中，从根本上切断了“调用外部错误版本”的可能性。

conda环境下安装并执行uwsgi正确方式

采用 conda 创建的版本环境 python3.8 中，切换到 venv 虚拟环境下，执行 pip install -r requirement.txt 安装所有依赖包
deactivate venv 环境，conda activate python38 切到 conda 版本环境中
执行 conda install -c conda-forge uwsig （-c 是渠道的意思，conda-forge 这个镜像渠道有很全的软件包）
然后将配置文件 uwsig.ini——>home 指向虚拟目录

[uwsgi]
# Django manage.py 所在文件夹路径
chdir = /Users/senwang/workspace/python-api/
module = plus.wsgi:application
# 启用master进程管理
master = true
# 绑定的 UNIX socket
http = 127.0.0.1:8888
# uwsgi的进程数
processes = 1
# 最大请求处理数，之后重新生成进程
max-requests = 5000
# 退出时清理环境
vacuum = true
# python的安裝路径
home=/Users/senwang/workspace/python-api/venv/