pdm install --prod仅安装[project.dependencies]和[dependency-groups.production]中的依赖，跳过dev组；CI/CD中应优先使用pdm sync --prod直接按lockfile还原，更快更确定。
怎样用 pdm install --prod 正确安装生产依赖
直接运行 pdm install 默认会装全部依赖（包括 [project.optional-dependencies.dev] 里的测试、格式化等工具），这不是生产环境想要的。必须显式加 --prod 才跳过 dev 组。
-
pdm install --prod只读取[project.dependencies]和[dependency-groups.production]（如果定义了） - 它仍会解析依赖树、生成/更新
pdm.lock，但不会碰dev组声明 - 若项目没定义
dev组，--prod和默认行为效果一致——但这不是常态，别依赖它 - CI/CD 中更推荐用
pdm sync --prod，它跳过解析，直接按 lockfile 安装，更快也更确定
为什么 pdm add requests 不等于“已装上”
新手常以为执行 pdm add requests 后就能立刻 import requests，其实它只改 pyproject.toml 并触发 lockfile 更新，不落地任何文件到 __pypackages__/ 或虚拟环境。
- 真正解压安装发生在
pdm install阶段：它读pdm.lock，按锁定版本把包放进__pypackages__/3.11/lib（或.venv/lib，取决于配置） - 所以
pdm add+pdm install --prod是完整闭环，漏掉后者就等于“写了菜谱但没炒菜” - 如果
pyproject.toml里已有dependencies，但没运行过install，__pypackages__/就是空的，pdm run python -c "import requests"也会报ModuleNotFoundError
如何让 pdm.lock 真正锁定生产环境行为
pdm.lock 默认包含所有依赖组（dev, test, docs 等），但生产环境只需要其中一部分。靠 --prod 参数控制安装范围，不等于 lockfile 本身被裁剪。
- lockfile 本身不区分“生产/开发”，它是全量快照；区别只在
install或sync时读哪部分 - 若想让 CI 构建完全隔离 dev 工具（比如防止某次
mypy升级意外影响运行时），应在pyproject.toml中明确拆分： [dependency-groups.production] = ["requests", "fastapi"][project.optional-dependencies.dev] = ["pytest", "black"]- 然后始终用
pdm install --prod --group production，避免隐式 fallback 到[project.dependencies]
Docker 或 CI 中用 pdm sync --prod 而非 install
pdm install 在每次运行时都会重新解析依赖图（即使 lockfile 没变），而 sync 直接按 lockfile 二进制还原，省去解析开销，且杜绝因网络、镜像源波动导致的版本漂移。
立即学习“Python免费学习笔记（深入）”；
-
pdm sync --prod是部署阶段唯一应使用的命令 - 它要求
pdm.lock必须存在且已提交，否则失败——这反而是优点：强制团队养成“先锁再发”的习惯 - 注意：如果项目禁用了虚拟环境（
pdm config python.use_venv false），sync会直接写入__pypackages__/，此时需确保运行用户有写权限 - 常见错误：
ERROR: No lockfile found. Please run 'pdm lock' first.—— 这不是 bug，是设计：没有 lockfile 就不允许同步
requires-python 或 python-constraints，而取决于你是否在每次变更后运行 pdm lock，以及是否在部署时严格使用 sync --prod。lockfile 是契约，不是备忘录。 
