使用Gunicorn在虚拟环境(Venv)中运行DRF接口的问题

不能仅凭VIRTUAL_ENV为None判定未在venv运行 #

直接调用venv内的gunicorn二进制文件时，不会触发venv激活脚本的VIRTUAL_ENV环境变量设置，但Python解释器确实是venv内的版本。这个变量只是激活脚本的附加设置，并非venv运行环境的核心标识。

强制让代码在venv中运行的方法 #

• 先激活venv再启动gunicorn：

  source /path_to_venv/bin/activate && gunicorn your_wsgi_entry:application
  

  激活后VIRTUAL_ENV会被正确设置，且PATH优先使用venv内的依赖。
• 直接指定venv内的Python启动gunicorn：

  /path_to_venv/bin/python /path_to_venv/bin/gunicorn your_wsgi_entry:application
  

  彻底绕过系统Python，确保解释器和依赖都来自venv。
• 手动设置VIRTUAL_ENV变量（若业务代码依赖该变量）：

  VIRTUAL_ENV=/path_to_venv /path_to_venv/bin/gunicorn your_wsgi_entry:application
  

验证代码是否在venv中运行的可靠方法 #

• 打印Python解释器路径：
  在API代码中添加：

  import sys
  print(sys.executable)
  

  输出应为/path_to_venv/bin/python，说明使用venv内的解释器。
• 检查依赖包路径：
  以DRF为例，添加代码：

  import rest_framework
  print(rest_framework.__file__)
  

  路径应包含/path_to_venv/lib/pythonX.X/site-packages（X.X为你的Python版本）。
• 查看进程信息：
  执行ps aux | grep gunicorn，确认进程命令行指向venv内的gunicorn；或用lsof -p <gunicorn进程ID>，检查加载的库文件路径是否来自venv。

内容的提问来源于stack exchange，提问作者Larry Martell