pipenv --python 3.9与pipenv install --python 3.9区别及搭建疑问

疑问解答 #

Q1：pipenv --python 3.9 和 pipenv install --python 3.9 作用是否一致，步骤3应该用哪个？ #

两个命令作用完全不一致，不存在必须替换的说法：

• pipenv --python 3.9：仅执行虚拟环境初始化操作，绑定指定的3.9版本Python解释器，执行后只会在项目目录生成基础配置文件Pipfile，不会安装任何依赖，也不会生成版本锁定文件Pipfile.lock。
• pipenv install --python 3.9：是组合操作，先完成「创建虚拟环境+绑定指定Python版本」的步骤，之后自动执行依赖安装流程：如果当前目录存在requirements.txt，会默认读取文件内的依赖列表完成安装，同时生成Pipfile.lock；如果没有依赖文件则初始化空的依赖配置。

你当前的步骤里单独拆分了安装requirements的步骤，用pipenv --python 3.9是没问题的，不需要强行替换成install版本。

Q2：为什么要在进入虚拟环境前指定Python版本，进入环境后再指定是否可行？ #

不可行。
pipenv的虚拟环境是和项目目录强绑定的，Python解释器版本是虚拟环境第一次创建时就固定的底层配置，创建完成后无法热修改。
如果你跳过步骤3直接执行pipenv shell，pipenv会自动用系统当前默认的Python版本创建虚拟环境，等你进入环境之后再执行版本指定命令不会生效——要修改Python版本必须先删除现有虚拟环境（执行pipenv --rm），重新创建时再指定版本，完全没必要多此一举。

现有步骤的问题与补充操作 #

你列的流程可以跑通，但存在几个容易踩坑的点，建议调整补充：

• 修正依赖导出逻辑：步骤2直接在全局pip环境执行pip freeze > requirements.txt会导出大量和当前项目无关的全局冗余包，后续安装容易触发版本冲突。如果之前的项目是在独立虚拟环境中开发的，要切到对应旧虚拟环境再执行pip freeze；如果之前一直用全局环境开发，建议用pipreqs工具扫描项目代码的实际import语句，生成仅包含项目用到的依赖的requirements文件。
• 增加版本校验步骤：执行完pipenv --python 3.9后，先跑pipenv run python --version确认输出的Python版本确实是3.9.x，避免因为系统没装对应版本、pipenv自动 fallback 到其他Python版本你没发现，后续出现兼容问题。如果提示找不到对应Python，可以直接写解释器全路径指定，比如pipenv --python /usr/bin/python3.9（Linux/macOS）或者pipenv --python C:\Python39\python.exe（Windows）。
• 补充版本锁定操作：步骤5安装完所有依赖后，执行pipenv lock生成完整的Pipfile.lock文件，这个文件会记录所有依赖的精确版本和哈希值，是后续部署时保证环境一致性的核心，比requirements.txt的可靠性高很多。后续生产环境部署时不需要再带requirements.txt，只要把Pipfile和Pipfile.lock传到服务器，执行pipenv install --deploy就可以严格按照锁定版本安装依赖，不会出现版本漂移问题。
• 可选校验操作：依赖全部安装完成后可以执行pipenv check，扫描已安装包是否存在已知的安全漏洞，提前排查风险。
• 配置忽略文件：记得在项目根目录的.gitignore中添加pipenv相关的忽略规则，不需要把虚拟环境本身提交到代码仓库，只需要提交Pipfile、Pipfile.lock和项目业务代码即可。

内容的提问来源于stack exchange，提问作者user9532692