poetry.lock 比 requirements.txt 更可靠，因其是含 SHA256 哈希、平台标识与完整依赖路径的机器可执行可信快照，安装时强制校验；而 requirements.txt 仅存包名与版本号，无校验、无间接依赖声明、不保证跨环境一致性。
因为 poetry install 不是“装列表”，而是“还原快照”——它靠 poetry.lock 里记录的精确版本、哈希值和完整依赖链，在任意机器上复现一模一样的环境；而 pip install -r requirements.txt 只读文本、不校验、不解析，同一份文件在不同时间、不同机器上很可能装出两套不兼容的包。
poetry.lock 为什么比 requirements.txt 更可靠
poetry.lock 是机器可执行的可信快照，不是给人改的配置文件。它包含每个包的 SHA256 哈希、来源 URL、传递依赖的完整路径，安装时默认强制校验——下载内容与哈希不匹配就报错中断。而 requirements.txt 只存包名和版本号（比如 requests==2.31.0），但 PyPI 上同版本可能有多个 wheel（macOS / Linux / Windows / CPU / CUDA 构建版），pip 完全不校验，静默选一个装，CI 里跑通、本地运行时报 ImportError 就很常见。
- 删掉
poetry.lock后再poetry install，会触发全新依赖解析并生成新锁文件——这不是“重装”，而是重新验证整个依赖树是否仍可解 - 手动编辑
poetry.lock后必须运行poetry lock --no-update重生成，否则下次install会拒绝执行 -
requirements.txt没有哈希、没有平台标识、没有间接依赖声明，根本无法表达“这个 requests 必须带 urllib3 1.26.15 且不能升级到 2.x”这类约束
poetry add 和 pip install 的行为本质不同
poetry add 是声明式操作：它修改 pyproject.toml 中的约束（如 ^2.31.0），然后调用内置解析器重算整棵树，更新 poetry.lock 并同步安装；pip install requests==2.31.0 是命令式操作：直接下载安装，不管其他包是否因此被覆盖或冲突。
- 加一个 dev 包：
poetry add pytest --group testing只写进[tool.poetry.group.testing.dependencies]，poetry install默认不装它；pip install pytest会立刻进当前环境，还得手动记着删 - 升级主依赖：
poetry add requests@2.32.0会检查所有依赖是否仍兼容，冲突时明确报错位置；pip install requests==2.32.0直接覆盖，可能让urllib3或charset-normalizer版本断裂 -
poetry add支持@语法指定源（如poetry add torch --source pytorch），pip要配--index-url参数且不保存到配置里
虚拟环境管理不是“自动激活”，而是上下文绑定
Poetry 不修改 shell 的 $PATH，也不依赖你记得 source venv/bin/activate；它的 poetry run 和 poetry shell 是 exec 替换，确保子进程用的一定是该项目专属环境里的 Python 和包。
立即学习“Python免费学习笔记（深入）”；
- 在 CI 中写
poetry run python train.py，哪怕 runner 是干净系统，也绝不会误用全局python或pip -
poetry shell进入的是隔离 shell，退出后自动恢复，不像pipenv shell那样容易因新开 terminal tab 导致环境丢失 - PyTorch 项目常需匹配特定 CUDA 版本，Poetry 能配合
pyproject.toml中的[[tool.poetry.source]]指向https://download.pytorch.org/whl/cu118，pip每次都得手输--index-url
真正难的不是学会命令，而是理解 poetry.lock 不是中间产物，而是部署契约；pyproject.toml 里写的不是“我要装什么”，而是“我承诺兼容哪些约束”。一旦跳过校验、手改锁文件、或混用 pip install，整个可重现性就塌了。
