不用 Python venv，那用什么
多年来 python -m venv .venv 一直是 Python 依赖管理和隔离的默认答案。它能用、内置在 Python 里、几乎所有教程都假设你会用它。但现在越来越多开发者问：我真的还需要 venv 吗？答案：不总是。这篇 dev.to 教程梳理了现代替代方案和各自适用的场景。
方案一：uv
Python 工具链目前最大的动量转移可能就是 uv——基于 Rust 的包管理器，目标极快，同时简化依赖与环境管理。安装：curl -LsSf https://astral.sh/uv/install.sh | sh。然后 uv init my_app 创建项目目录（.python-version、main.py、pyproject.toml、README.md），uv run main.py 直接运行，uv add requests 添加依赖——此时 uv 自动创建 .venv 并把依赖装进去。
方案二：Poetry
uv 之前，Poetry 常被视为"现代 Python 工作流"工具。安装：curl -LsSf https://install.python-poetry.org | python3 -。poetry new myapp 生成 src/myapp/init.py、tests/init.py、pyproject.toml、README.md——注意项目目录里没有 .venv，Poetry 默认把所有虚拟环境集中存在一个位置（Linux 上通常在 ~/.cache/pypoetry/virtualenvs，每个项目一个专属环境）。poetry add requests 加依赖，poetry run python src/myapp/main.py 运行。
方案三：PDM
PDM 最初实现的是基于 PEP 582 的想法：不创建带独立解释器二进制的隔离虚拟环境，而是把依赖（仅 Python 依赖）放在项目内的本地 pypackages 目录。pdm new myapp 会交互式问一串问题（解释器版本、项目名、版本、许可证、作者、邮箱、是否初始化 Git），然后创建 .venv、.pdm-python、pyproject.toml。
但承诺的 pypackages 在哪？答案：PEP 582 从未被接受为官方 Python 标准，生态工具没有完全采纳它，现代 PDM 版本默认改用 .venv。真想用 pypackages 得显式配置：pdm config python.use_venv false。
方案四：容器代替环境
有些团队完全跳过 Python 环境，用容器隔离应用——依赖隔离发生在容器层而不是本地虚拟环境。这种设置里，专用 venv 变得不那么重要，因为容器本身就是隔离边界。
这些真的是 venv 的替代品吗
不完全是。大多数系统仍以某种形式依赖虚拟环境。最大的转变不是抛弃 venv，而是改变开发者思考 Python 项目的方式：传统 venv 工作流把虚拟环境当作独立实体，开发者显式创建、激活、挂到项目上；现代工具把这个模型翻转过来——项目成为主要单元，环境自动与之关联。于是不再是"我需要激活这个环境"，而是"我在做这个项目"，工具在幕后安静地确保正确的解释器和依赖就位。
对团队的实际建议：单人/小团队快速迭代用 uv（快、默认项目优先心智模型）；需要严谨依赖锁定和发布工作流选 Poetry；想试验 PEP 582 风格或已在 PDM 生态的直接用 PDM；容器化部署环境里可以淡化 venv 的存在感，但本地开发仍保留一个环境工具更顺手。venv 没有死，它变成了工具背后的默认引擎。