开发依赖和生产依赖的区别在于“该不该装”：生产环境只需运行代码的最小依赖集（如fastapi），开发依赖则是辅助编码测试的工具（如pytest）；混装会浪费资源并引发版本冲突。

开发依赖和生产依赖到底差在哪

区别不在“能不能跑”，而在“该不该装”。生产环境只需要运行代码的最小依赖集，比如 fastapi、sqlalchemy；而开发依赖是辅助你写代码、测代码、查代码的工具，比如 pytest、black、mypy。混在一起装，轻则浪费部署时间、增大镜像体积，重则因开发工具引入的间接依赖污染生产环境（例如某个 linter 依赖了旧版 click，而你的 API 正好也用 click，版本冲突直接报错）。

poetry add --group dev 和 --dev 参数的区别

新版 Poetry（1.4+）已弃用 --dev，统一用 --group dev。如果你在文档或老教程里看到 poetry add pytest --dev，它仍然能运行，但会输出警告，且未来版本会彻底移除。正确写法是：

poetry add pytest --group dev<br>poetry add mypy --group dev<br>poetry add ruff --group dev

这样添加的包会写进 pyproject.toml 的 [tool.poetry.group.dev.dependencies] 区块，而不是主依赖区。不加 --group 就默认进 [tool.poetry.dependencies]，也就是生产依赖。

poetry install --only main 为什么不能省略

CI/CD 流水线或容器构建时，如果只写 poetry install，它会把开发依赖也装上——这违反了最小权限原则，还可能触发不必要的编译（比如 mypy 装的时候会拉 mypy-extensions 和一堆类型 stubs）。必须显式指定：

• poetry install --only main：只装 [tool.poetry.dependencies] 下的包
• poetry install --only dev：只装开发组依赖（适合本地搭测试环境）
• poetry install --only main,dev：手动组合多个组（注意逗号无空格）

漏掉 --only main 是线上部署最常见的配置失误之一，错误日志里往往只显示 ModuleNotFoundError: No module named 'pytest' 这类误导信息，实际原因是误装了开发包导致主依赖被覆盖或路径错乱。

macOS UI 自动化技能包 —— 用 Python 控制你的 Mac

让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限

下载

自定义 dependency-group 的真实用途

除了 dev，你可以任意命名 group，比如 test、doc、ci，适用于更细粒度的场景：

poetry add sphinx --group doc<br>poetry add pytest-cov --group test

对应在 pyproject.toml 中生成独立区块：

[tool.poetry.group.doc.dependencies]<br>sphinx = "^7.2"

然后按需安装：poetry install --only doc。这种写法比在 requirements-docs.txt 里维护额外文件更可靠，因为所有 group 都受 poetry.lock 锁定，版本不会漂移。不过要注意：Poetry 不会自动推导 group 之间的依赖关系，比如 doc 组依赖 sphinx，而 sphinx 又依赖 docutils，这个 docutils 默认不会进 doc 组——它会被 Poetry 自动归入 main 组，除非你显式用 --group doc 再加一遍。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！