poetry install是“解析后装”，先读pyproject.toml并校验poetry.lock中的完整依赖树，冲突时明确报错；pip install -r requirements.txt是“盲装”，仅顺序执行文本指令，后写版本覆盖前写且不提示，易导致环境不一致。
不需要“掌握”Poetry，但如果你正在维护一个需要多人协作、要发版、要上 CI、依赖有冲突风险的 Python Web 项目（比如 FastAPI 或 Flask 应用），那么不使用 Poetry 很容易掉进环境不一致、依赖覆盖、dev/prod 混装的坑里。
poetry install 和 pip install -r requirements.txt 的行为差异在哪？
表面都是装依赖，实际逻辑完全不同：
-
pip install -r requirements.txt是“盲装”：只按文本顺序执行，遇到requests==2.28.0和requests>=2.31.0冲突时，后写的会覆盖前写的，不报错也不提示 -
poetry install是“解析后装”：先读pyproject.toml声明的约束，再比对poetry.lock中已验证过的完整依赖树；如果 lock 文件缺失或冲突，它会停住并明确告诉你哪两个包在争urllib3的版本 -
poetry install自动激活项目专属虚拟环境；pip install -r前必须手动source venv/bin/activate，漏了就污染全局 Python 环境
pyproject.toml 如何替代 requirements.txt + setup.py + MANIFEST.in？
不是“替代”，而是把多个文件语义合并进一个声明式配置：
-
[tool.poetry.dependencies]对应生产依赖（如fastapi = "^0.115.0"） -
[tool.poetry.group.dev.dependencies]对应开发依赖（如pytest = "^8.2.0"），CI 可用poetry install --without dev精准跳过 -
[tool.poetry.scripts]直接定义 CLI 入口，不用写setup.py中的entry_points -
[build-system]告诉构建工具（如pip wheel）该用什么 backend，无需setup.py存在
你删掉 requirements.txt 不会丢功能，但删掉 poetry.lock 就等于放弃可复现性——它记录每个包的精确哈希、来源 URL 和传递依赖链，不是给人改的。
立即学习“Python免费学习笔记（深入）”；
poetry add requests@2.31.0 为什么比手动改 requirements.txt 更安全？
因为版本变更从来不是孤立动作：
- 直接编辑
requirements.txt：改完requests版本 → 手动推断httpx、urllib3是否要同步调 →pip install -r→ 报错再查文档 → 可能误把black也写进生产依赖 -
poetry add requests@2.31.0：Poetry 自动重算整个依赖图，更新pyproject.toml和poetry.lock，确保httpx仍兼容、urllib3不越界、black仍在 dev 组里 - 加开发依赖必须显式加
--group dev，否则不会出现在poetry install默认安装列表中
真正容易被忽略的点是：Poetry 不解决“代码怎么写”，它只管“依赖怎么稳”。一旦你开始用 poetry publish 推包、用 poetry build 打 wheel、让 CI 跑 poetry install --no-dev，你就已经默认接受了它的契约——poetry.lock 必须提交进 Git，pyproject.toml 必须成为唯一真相源，而不再容忍任何手动生成的文本依赖清单。
