poetry 是独立的依赖管理+打包工具，需停用 pip install 和 requirements.txt；初始化用 poetry init 或 poetry new；依赖通过 poetry add 修改 pyproject.toml 并更新 poetry.lock，用 poetry install 按 lock 文件精确还原；ci 中应使用 poetry install --no-root；poetry.lock 必须提交 git 以保障可重现构建。
Poetry 不是 pip 的“升级版”，它本质是独立的依赖管理+打包工具，直接用 pip 安装 Poetry 后，就该彻底停用 pip install 和 requirements.txt 管理项目依赖——否则反而引发冲突。
初始化新项目时，别手动创建 venv 或 requirements.txt
Poetry 自带虚拟环境隔离和依赖解析逻辑，手动干预会绕过它的锁机制：
- 运行
poetry init交互式生成pyproject.toml，或直接poetry new myproject创建完整结构 - 不要提前
python -m venv .venv，Poetry 在首次poetry install时自动创建并激活专属环境 - 删掉任何残留的
requirements.txt，Poetry 不读这个文件；它只认pyproject.toml中的[tool.poetry.dependencies]和poetry.lock
poetry add 和 poetry install 的行为差异必须分清
这两个命令解决不同问题，混用会导致环境不一致：
-
poetry add requests：更新pyproject.toml并重写poetry.lock，但不立即安装——只记录“想装什么” -
poetry install：按poetry.lock精确还原依赖（包括子依赖版本），用于部署或协作同步 - 开发中常用
poetry add pytest --group dev把测试库放进[tool.poetry.group.dev.dependencies]，避免上线时误装
CI/CD 中必须用 poetry install --no-root
默认 poetry install 会把当前项目作为可安装包（执行 pip install -e .），这在 CI 构建镜像时往往不需要，还可能触发不必要的源码安装：
- CI 脚本里统一用
poetry install --no-root，只装依赖，跳过项目本身 - 如果项目需被其他包 import（如发布为 PyPI 包），才在本地保留默认行为；CI 中多数服务只需运行时依赖
- 注意
poetry export -f requirements.txt是妥协方案，仅用于兼容旧流程——导出结果不保证与poetry.lock完全一致，慎用
最常被忽略的是 poetry.lock 文件必须提交到 Git。它不是缓存，而是依赖快照；删掉它或忽略它，等于放弃可重现构建——哪怕只改一行代码，没它，下次 poetry install 就可能拉到不同版本的子依赖。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
