Python 虚拟环境怎么用？项目依赖隔离与可复现部署
虚拟环境把一个项目安装的 Python 包与其他环境分开，适合在同一服务器上管理多个应用。它不是虚拟机，也不会自动隔离文件、网络或系统权限。本文以 Ubuntu 24.04 的 Python 3.12 为例，目录和依赖文件需按实际项目替换。
先确认解释器与目录用途
执行 python3 --version，确认项目支持当前解释器，再准备由部署账号管理的独立发布目录。不要在系统 Python 包目录里手工覆盖文件，也不要为了安装某个应用就修改所有用户默认解释器。
如果系统提示缺少 venv 支持，应通过当前发行版认可的软件包补齐。不要用强行绕过系统包保护的参数代替正确环境管理。多个项目即使使用同一 Python 大版本，也可能需要不同的依赖组合。
在新发布目录创建环境
进入已经准备好的项目目录，确认 .venv 尚未承载其他发布，然后执行：
python3 -m venv .venv
.venv/bin/python --version
.venv/bin/python -m pip --version
使用完整的环境内解释器路径，可以避免当前终端没有激活环境时安装错位置。激活脚本主要影响 shell 的命令查找，并不是运行虚拟环境程序的唯一方式。Python venv 文档
虚拟环境通常包含与原位置相关的路径，不应当成可任意搬动的目录。迁移到新服务器或新的 Python 版本时，依据依赖记录重新创建，比直接复制整份环境更容易控制兼容性。
安装项目已经验证的依赖
如果项目使用已经审查并固定版本的 requirements 文件，可在环境中安装并检查：
.venv/bin/python -m pip install -r requirements.txt
.venv/bin/python -m pip check
requirements 文件是否足够可复现，取决于其中的版本、来源以及必要的校验安排，不是文件名本身提供保证。项目使用其他锁文件或构建工具时，应沿用其正式流程，不能随手导出一份包列表替代。
pip 检查依赖关系不代表应用测试全部通过，也不证明原生扩展和外部库在运行时一定可用。安装失败时区分 Python 版本不兼容、编译工具缺少和下载问题，不要把所有错误都当成网络故障。pip 用户指南
让服务明确使用这份环境
正式服务的启动命令应引用环境里的 Python、Gunicorn 或 Uvicorn 等实际程序路径。systemd、计划任务和手工终端未必共享相同 PATH，所以不能依赖管理员此前执行过一次 activate。
运行账号只需要读取程序和依赖，写入权限应留给明确的上传、缓存或运行目录。安装依赖通常由部署账号完成，不应让应用进程能够随时修改自己的全部依赖。仓库或安装脚本必须可信，因为构建和安装过程可能执行代码。
敏感配置与虚拟环境分开管理。不要把数据库密码放进依赖文件，也不要将带私有仓库令牌的安装命令复制到公开工单。日志中的下载地址也可能包含凭据，需要在分享前检查。
验收新环境，保留旧发布
先用环境内解释器验证应用导入、启动和必要的只读接口，再通过实际业务流程检查数据库、文件处理与后台任务。记录解释器版本、依赖锁文件与构建结果，保证另一台服务器能够重复建立相同环境。
发布失败时，恢复仍然保留的旧发布目录及其环境，比在生产环境里连续升降依赖更容易解释。若应用已经改变数据库结构，先确认旧代码兼容性。回退完成后再分析新环境，不要把正在被旧进程使用的环境直接删除或重建。