poetry 安装依赖提速需三步：一配镜像源（如清华或阿里云）加速元数据与包下载；二启用并行安装（poetry config installer.parallel true）；三预热缓存（导出依赖后逐个add --no-install）。
直接结论：不配镜像源，Poetry 安装依赖永远快不了；只配镜像源，还有一半性能浪费在重复解析和串行下载上。
poetry config repositories.pypi 是必须第一步
Poetry 默认走 https://pypi.org/simple，国内访问延迟高、丢包率高，Resolving dependencies 卡住不是 bug，是网络现实。必须显式配置镜像源，且要配对——既要加速元数据查询（解析阶段），也要加速包文件下载（安装阶段）。
- 全局配置（推荐）：
poetry config repositories.pypi https://pypi.tuna.tsinghua.edu.cn/simple/ - 项目级配置（团队协作首选）：在项目根目录执行
poetry config repositories.pypi https://mirrors.aliyun.com/pypi/simple/，会写入poetry.toml - 别碰 pip 的
pip.conf：Poetry 1.5+ 已完全接管源管理，pip 配置可能被忽略或冲突
poetry config installer.parallel = true 能省掉 30%–60% 时间
默认 Poetry 安装依赖是串行的，尤其当 poetry.lock 里有几十个包时，一个接一个下载解压，非常低效。启用并行后，Poetry 会按依赖拓扑分组并发下载和安装，实测在中大型项目中可减少近半耗时。
- 执行：
poetry config installer.parallel true - 注意：Windows 上部分旧版 PowerShell 可能因权限问题报错，换用 CMD 或 Git Bash 更稳
- 不需要额外参数，所有后续
poetry install和poetry add自动生效
缓存预热比“等它自己缓”靠谱得多
Poetry 缓存（~/.cache/pypoetry 或 %APPDATA%\pypoetry\Cache）本身有效，但默认是被动写入——只有真正安装过某包，才会存下来。CI 构建或新同事拉代码时，第一次仍要全量下载。
- 主动预热方法：先用
poetry export -f requirements.txt --without-hashes > reqs.txt导出无哈希依赖清单 - 再执行：
while read p; do poetry cache clear "$p" 2>/dev/null; poetry add "$p" --no-install; done - 关键点：
--no-install只下载不安装，避免环境污染；poetry cache clear强制触发下载进缓存 - 这招特别适合 Jenkins/GitLab CI，在构建前跑一次，后续所有
poetry install基本秒出
poetry install --no-dev 不是“省时间”，是绕开解析炸弹
开发依赖（如 pytest、mypy、black）往往自带大量间接依赖，且版本约束松散。Poetry 在解析时会把它们全纳入计算图，导致 Resolving dependencies 时间指数级增长。生产环境或 CI 测试阶段根本用不到它们。
- 上线部署或轻量测试时，强制加
--no-dev：poetry install --no-dev - CI 中建议拆成两步：
poetry install --no-dev+poetry install --only dev（后者仅在 lint/test 阶段运行） - 别信
poetry install --with dev：它不会跳过解析，反而让整个图更复杂
最常被忽略的是：Poetry 的解析慢，70% 源于网络，30% 源于没关掉 dev 依赖的爆炸式求解。镜像源 + 并行 + --no-dev 这三者组合使用，才能真正把 poetry install 从“泡茶等待”变成“敲完回车就完事”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
