Poetry默认将python字段视为最低兼容版本（如"^3.9"），而非锁定版本，故不写死小版本；生产需显式设为"3.9.18"并重生成poetry.lock以确保环境一致。
为什么 poetry init 生成的 pyproject.toml 默认不写死 Python 版本？
因为 Poetry 默认把 python 字段当作“最低兼容版本”而非“锁定版本”，比如写成 python = "^3.9"，实际会允许 3.9.0 到 3.10.0（不含）之间的解释器——这在 CI 或生产部署时可能引发意外行为。
生产项目必须显式锁定 Python 小版本：
- 运行
poetry env use 3.9.18（先确保本地装了该版本） - 再执行
poetry env info --path确认虚拟环境路径是否已切换 - 最后手动编辑
pyproject.toml，把python = "^3.9"改成python = "3.9.18"
注意：改完后要删掉 poetry.lock 并重新 poetry lock，否则旧 lock 文件仍可能拉取不兼容的包变体。
poetry install 和 poetry install --no-dev 在生产部署中怎么选？
poetry install 默认装所有依赖（包括 [tool.poetry.group.dev.dependencies]），而生产环境不该有 pytest、black 这类开发工具——它们不仅增大镜像体积，还可能引入非预期的运行时依赖。
立即学习“Python免费学习笔记（深入）”；
正确做法是：
- CI/CD 构建阶段用
poetry install --no-root（跳过当前项目自身安装，只装依赖） - 生产部署时明确用
poetry install --no-dev --no-root - 如果项目是库（非可执行应用），还需加
--only main避免误装其他 group
别依赖 poetry export -f requirements.txt 生成文件再 pip 安装——它会丢失 Poetry 的精确锁版本和 extras 信息，且不处理 platform 或 marker 条件依赖。
如何让 Poetry 生成的虚拟环境被 systemd / Docker 正确识别并复用？
Poetry 默认把虚拟环境放在 ~/.cache/pypoetry/virtualenvs/，这对单机开发没问题，但 systemd 服务或容器内常以非交互用户运行，~ 路径不可靠，且不同机器上环境路径不一致，导致 ExecStart=... 写死路径容易失效。
解决方式是统一指定环境位置：
- 在项目根目录下设
poetry.toml，写入：[virtualenvs] path = "{cache-dir}/virtualenvs" - 更推荐直接用环境变量：
export POETRY_VENV_PATH="./.venv"（配合.env或启动脚本） - Docker 中建议在
Dockerfile里RUN poetry config virtualenvs.path /app/.venv，再poetry install --no-dev
这样所有环境都落在项目目录内，systemd 可直接写 ExecStart=/app/.venv/bin/python app.py，无需查路径或激活 shell。
为什么 poetry add requests@^2.31 有时不生效，或升级后出错？
因为 @^2.31 是语义化版本范围，不是精确版本；Poetry 解析时优先满足已有依赖约束，若 pyproject.toml 里已有其他包依赖 requests，那这条命令会被静默忽略或回退。
真正可控的操作是：
- 查冲突：运行
poetry show requests --tree看谁在依赖它 - 强制重写：用
poetry add requests==2.31.0（双等号=精确匹配） - 批量更新：先
poetry update，再poetry add requests@^2.31，避免中间状态卡住 - 验证锁：改完立刻
poetry lock --no-update检查poetry.lock是否真更新了requests的version和source字段
最容易被忽略的是：Poetry 不会自动降级已安装的包，哪怕 pyproject.toml 里写了更低版本——必须 poetry install 或 poetry update 才触发重算与重装。
