venv、conda、poetry，小团队到底该选哪个管依赖

组里新项目起步，为「用什么管Python依赖」开了一次会，三种方案各有拥趸。我把三者的定位和实测体验整理下来，最后我们按项目类型做了拆分选择。

venv：标准库的底线方案

venv是Python 3.3+自带的虚拟环境工具，只解决「环境隔离」这一件事：

python -m venv .venv
.venv\Scripts\activate     # Windows
source .venv/bin/activate  # Linux/macOS
pip install -r requirements.txt
pip freeze > requirements.txt

优点是零依赖、到处都有；缺点是pip的依赖解析较弱，requirements.txt只锁版本列表，不锁哈希，跨机器复现偶尔翻车。小脚本和CI里跑一次性任务，我仍然用它。

conda：科学计算的舒适区

conda把Python本身也当成包来管理，能装不同版本的Python解释器，还能装CUDA这类非Python依赖，numpy、scipy的二进制包适配极好。缺点是体积巨大（base环境动辄几个GB），channel优先级配置不当会出现「Solving environment」转圈几分钟的噩梦。做算法和数据的项目我们保留了conda（通常是miniconda加conda-forge频道），纯后端项目一律不用。

poetry：应用项目的工程化

poetry用pyproject.toml声明依赖，poetry.lock锁精确版本和哈希：

poetry init
poetry add requests redis
poetry install            # 按lock精确还原
poetry run pytest

依赖解析完整，dev依赖和正式依赖分组管理，打包发布一体。上手成本是命令体系要记一套，早期版本在私有源配置上也踩过坑。我们两个对外服务都迁到了poetry，CI里poetry install后跑测试，再没出现过「本地能跑线上装不上」。

决策建议

• 单文件脚本、教学demo：venv或干脆uv（更快的后起之秀）
• 数据科学、需要非Python依赖：miniconda
• 要长期维护的应用、多人协作：poetry或uv，核心是pyproject.toml加锁文件

无论选哪个，务必把锁文件提交进git，把环境目录加进.gitignore。工具之争不重要，可复现才重要。