依赖准备升级时，可以先让 pip 只做解析，不改当前环境：
环境：Python 3.11+，pip 22.2+。在一个临时虚拟环境里执行：
python -m venv .venv
. .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install --dry-run --report install-report.json \
\"httpx==0.27.2\"
终端会显示计划安装的包，install-report.json 里还会记录解析到的版本、下载地址和元数据。确认结果后，去掉 --dry-run 再执行实际安装。
这个方式适合在升级依赖前留一份机器可读的预览；Windows 激活虚拟环境时把第二行换成 .venv\Scripts\activate。
补充一点，--report 生成的 JSON 很适合放进 CI 做人工确认或 diff，但里面会带下载链接和包元数据。提交到构建产物前我会先检查一下是否包含内部源地址；真正安装时也记得用同一个 Python 环境，避免预览和实际执行不是一套解释器。
再补一个边界：install-report.json 记录的是这次解析出来的安装计划和元数据，不等于锁文件。它适合审阅、留痕或做差异比较，但不能单独拿来保证下一次安装一定复现同一组版本；需要可复现安装时，还是要配合项目自己的约束/锁定方案。
另外，报告可能包含包的下载地址和哈希，作为构建产物保存前可以按项目的敏感信息规则过一遍。
这个命令还有个小坑：解析结果会受当前环境影响。环境里已经装着满足条件的包时，dry-run 可能看起来很安静，不一定代表从零安装也一样。
如果是想看升级会牵动哪些依赖，可以在临时 venv 里明确加上要升级的包和 --upgrade 跑一遍；如果是确认项目当前环境有没有冲突，跑完实际安装后再接一个 python -m pip check 会更踏实些。
Nathan03Lv1#3 这个命令还有个小坑：解析结果会受当前环境影响。环境里已经装着满足条件的包时，dry-run 可能看起来很安静，不一定代表从零安装也一样。
如果是想看升级会牵动哪些依赖，可以在临时 venv 里明确加上要升级的包和
--upgrade跑一遍；如果是确认项目当前环境有没有冲突，跑完实际安装后再接一个python -m pip check会更踏实些。
还有一个容易漏的点：如果 CI 和本地使用的索引源、约束文件不一样，--report 的解析结果也可能不同。需要做升级评审时，可以把同一份 --constraint 文件和索引配置带上，再比较报告；这样 diff 才更有参考价值。报告里若出现内部索引地址，也别直接作为公开构建产物保存。
Nathan03Lv1#3 这个命令还有个小坑：解析结果会受当前环境影响。环境里已经装着满足条件的包时，dry-run 可能看起来很安静，不一定代表从零安装也一样。
如果是想看升级会牵动哪些依赖，可以在临时 venv 里明确加上要升级的包和
--upgrade跑一遍；如果是确认项目当前环境有没有冲突，跑完实际安装后再接一个python -m pip check会更踏实些。
如果想尽量模拟“全新环境”的安装计划，可以再加 --ignore-installed，避免当前环境里已经满足条件的包被跳过：
python -m pip install --dry-run --ignore-installed --report install-report.json \
"httpx==0.27.2"
这样更适合看完整的解析结果；但它仍然只是一次解析预览，最终结果还会受 Python 版本、平台和索引配置影响。
ZiorLv1#5 如果想尽量模拟“全新环境”的安装计划，可以再加
--ignore-installed，避免当前环境里已经满足条件的包被跳过：python -m pip install --dry-run --ignore-installed --report install-report.json \ "httpx==0.27.2"这样更适合看完整的解析结果；但它仍然只是一次解析预览，最终结果还会受 Python 版本、平台和索引配置影响。
如果输入是 requirements.txt，预览时最好把入口和约束一起固定下来，例如 python -m pip install --dry-run --report install-report.json -r requirements.txt -c constraints.txt。同一份报告在不同 Python 版本、平台或索引源下可能不同，CI 里把这些环境信息也记下来，之后看 diff 才不容易误判成依赖自己变了。
Nathan03Lv1#3 这个命令还有个小坑：解析结果会受当前环境影响。环境里已经装着满足条件的包时，dry-run 可能看起来很安静，不一定代表从零安装也一样。
如果是想看升级会牵动哪些依赖，可以在临时 venv 里明确加上要升级的包和
--upgrade跑一遍；如果是确认项目当前环境有没有冲突，跑完实际安装后再接一个python -m pip check会更踏实些。
如果目标是评估一次“整体升级”会牵动什么，除了 --upgrade 还可以明确写 --upgrade-strategy eager；默认的 only-if-needed 可能只升级直接指定的包。两种策略各跑一份 report，对比依赖树会更直观。
我一般不会直接对整个 install-report.json 做 diff，里面的下载地址、哈希和元数据字段容易带来不少噪声。CI 里可以先提取每个安装项的包名、版本和来源，再按包名排序后比较；原始报告保留作审计，稳定字段用于评审，结果会清楚很多。