Python 3安装与Python 2卸载全攻略：各平台操作与避坑指南

1. 为什么Python 2必须退场，以及卸载前必须想清楚的三件事

先聊点实际的。2020年1月1日Python 2官方停止维护那天，我手头还有三台服务器跑着Python 2.7写的内部工具，有数据清洗脚本，有自动化报表，还有一个定时抓取业务系统数据的爬虫。当时觉得"反正还能跑，不升就不升吧"，结果后来装一个第三方库时发现版本不兼容，才被迫开始大规模迁移。真正动手后才发现，Python 2退场不是"换个解释器"这么简单，它牵扯到语法差异、依赖库版本、系统底层工具链，一不小心就把环境搞崩。

如果你现在也是"电脑里有Python 2残留、想升级到Python 3"，我建议先别急着下载安装包，把下面三件事想清楚。

第一，确认系统是否默认依赖Python 2。特别是Linux/macOS系统，很多系统工具（比如Linux里的yum、某些发行版里的包管理脚本）底层还是调用Python 2的。你要是手一抖把Python 2直接删了，系统工具可能当场罢工。这不是危言耸听，我见过有人把/usr/bin/python指向Python 3之后，yum直接报错，最后只能靠救援模式把软链接改回来。所以下面的步骤里，我会专门说怎么安全处理这个"系统依赖"问题。

第二，分清你的Python 2是"自己装的"还是"系统自带的"。Windows上通常是自己装的，卸载相对干净；Linux上则要区分是yum install python2装的，还是系统里天生就有的。两者卸载方式完全不同，混着来很容易留下残缺文件，下次装Python 3时路径冲突，烦死你。

第三，你的旧项目里有没有必须用Python 2才能跑的代码。Python 2和Python 3在语法上有不少差异，最经典的是print从语句变成了函数，/除法的行为也变了，字符串编码更是重灾区。如果你有旧代码依赖Python 2的Unicode处理方式，强行切到Python 3会出一堆乱码问题。最稳妥的做法是：先把Python 3下载安装好，让新旧版本共存一段时间，等确认脚本全部跑通，再考虑卸载Python 2。

这篇文章我就把"Python 3下载安装 + Python 2卸载"这件事拆开揉碎，分别讲Windows、Linux和macOS三种环境下的完整流程，每步都告诉你为什么要这么干，以及最容易踩的坑在哪。内容是我近几年在真实服务器和个人电脑上反复操作的总结，不是那种只能看不能用的教程。

2. Python 3各平台下载安装的完整操作与路径管理

2.1 Windows：官网下载安装包，勾选Add to PATH是关键

Windows装Python 3其实是最省心的，但省心不等于没有坑。下面是标准流程。

先去Python官网（python.org）的Downloads页面，挑一个你需要的版本。别一上来就追最新版，很多第三方库的兼容性往往滞后。我个人习惯用"最新稳定版往前退一个小版本"的版本，比如最新是3.12，我就装3.11，库兼容性最稳。下载时注意区分32位还是64位，现在新电脑基本都64位，直接选Windows installer (64-bit)。

安装时有个复选框叫"Add Python to PATH"，一定要勾选。这是新手最容易忽略的，不勾的话装完后在cmd里敲python会提示找不到命令。勾选后安装程序会在系统环境变量PATH里自动加上Python目录和Scripts目录，省得你手动配置。

安装方式我推荐选"Customize installation"，虽然"Install Now"也能用，但自定义安装可以让你确定安装路径和可选组件。这里有个细节：安装路径建议改成不含空格的目录，比如D:\Python311。默认的C:\Users\用户名\AppData\Local\Programs\Python\Python311包含空格和中文用户名，少数老旧的第三方库在import时会因为路径问题报错，我确实遇到过。

组件配置里如果你是做爬虫或数据分析的，记得勾选"pip"和"py launcher"，前者是包管理工具，后者是帮你管理电脑上多个Python版本的工具。装完打开cmd，输入：

python --version

如果显示Python 3.x.x，说明装好了。这时候可以顺手验证下pip：

pip --version

2.2 Linux：主流发行版的Python 3安装方式和路径冲突

Linux的情况比Windows复杂，因为很多发行版自带Python 3。先看系统里有没有：

python3 --version

如果显示Python 3.x，那就不用装了，直接用。但如果你想要一个独立的新版本（比如系统自带3.6，你想用3.11），有两个主流方式。

方式一：用系统包管理器装。Ubuntu/Debian用apt，CentOS/RHEL用yum或dnf。以Ubuntu安装Python 3.11为例：

sudo apt update sudo apt install python3.11

装完后验证下python3.11 --version。这种方式的好处是库和路径都被系统统一管理，不太容易出乱子。缺点是版本一般比官网慢一点，不是最新。

方式二：从源码编译安装。想要最新版或者想自定义安装路径，就自己编译。这个流程适合有Linux基础的人，新手建议先用系统包管理器。

# 下载源码包 wget https://www.python.org/ftp/python/3.11.0/Python-3.11.0.tgz # 解压 tar -xzvf Python-3.11.0.tgz cd Python-3.11.0 # 配置安装路径，建议独立目录，避免和系统Python冲突 ./configure --prefix=/usr/local/python311 --enable-optimizations # 编译安装 make -j$(nproc) sudo make install

编译时那两个参数说一下。--prefix指定安装目录，我刻意让Python 3.11装在/usr/local/python311，这样和系统自带的Python 3完全隔离，不会出现"明明升级了程序却还在跑旧版本"的诡异情况。--enable-optimizations会做性能调优，编译时间会长一些，但运行时速度更好。

装完后设置环境变量：

# 编辑用户级环境变量文件 echo 'export PATH=/usr/local/python311/bin:$PATH' >> ~/.bashrc source ~/.bashrc

这样输入python3就会优先用新版本了。注意，最好不要去改/usr/bin/python3这个软链接，因为系统很多服务脚本在调用它，一改就会引发连锁反应。

2.3 macOS：pyenv管理多版本比直接装更省心

macOS上系统自带的Python 3其实是Apple为了让Xcode等工具正常运行而打包的，不建议直接用它来做开发，更不建议删掉系统Python。我的做法是装pyenv，专门用来管理多个Python版本。

首先确保装了Homebrew，然后：

brew install pyenv

之后在~/.zshrc里加入初始化配置：

eval "$(pyenv init -)"

注意，如果你用zsh，配置文件是.zshrc；如果还在用老的bash，就是.bashrc或.bash_profile。改完记得source一下。

然后用pyenv安装Python 3.11：

pyenv install 3.11.0

安装过程中pyenv会自动编译，同样需要等待。装好后设置全局版本：

pyenv global 3.11.0

这时候再敲python --version，就是Python 3.11了。pyenv的核心价值在于：它会在PATH最前面插入一个shims目录，让你的python命令动态指向当前项目或全局配置的版本，不同项目用不同Python版本互不干扰。现状是很多依赖指定了Python版本的项目，靠pyenv完美解决。

macOS这条路我之所以推荐给大多数人，是因为它从一开始就不需要操心"删掉系统Python"这个问题——你用pyenv，系统Python就当它不存在好了，各过各的。

2.4 环境变量和"python"与"python3"命令的差异

不管是哪个平台，装完Python 3后都要搞清楚一个问题：你终端里敲的到底是python还是python3？

Windows下，如果你勾选了"Add to PATH"，一般python和python3都能用。但在Linux和macOS上，这俩命令可能指向完全不同的版本。很多新手就是在这一点上吃了亏：明明python3已经是很新的版本了，但脚本或命令行里用的是python，跑的却是老掉牙的Py2或者一个奇怪的旧版本。

想确认你到底用的哪个Python，可以用下面这行命令，它会打印出Python解释器的真实路径：

which python which python3

Windows上用：

where python

如果输出路径不一样，说明你确实有两个Python在抢命令。最稳妥的做法是：统一在脚本或命令里显式写python3，并在虚拟环境里工作，而不是依赖系统级python命令。

说到虚拟环境，这里必须插一句：Python 3.3以上的venv就是隔离环境的标准工具，强烈建议一上来就养成"每个项目建一个venv"的习惯。原因很简单——你全局环境里装了一堆库，总会撞车的，A库要numpy 1.x，B库要numpy 2.x，全局只可能有一个。venv把每个项目的依赖隔离在一个独立目录里，再也不会出现这种冲突。

创建venv的命令：

python3 -m venv myproject_env source myproject_env/bin/activate # mac/linux myproject_env\Scripts\activate # windows

建好venv后，pip安装的包都会装进这个环境的site-packages，和系统其他Python完全隔离。我自己的所有项目都这么管理，时间长了你就知道这个习惯有多值钱。

3. Python 2卸载的完整流程与系统依赖风险排查

3.1 先判断你的Python 2是"系统依赖"还是"独立安装"

这一步绝对不能跳过，我前面踩过坑，这里必须说得极端清楚。

先看系统里Python 2在哪里：

Windows上，打开"控制面板 -> 程序和功能"，看有没有Python 2.x的条目。有的话说明是独立安装的，后面直接用卸载程序就行。但Windows上也可能存在"别人打包软件时代带进来的Python 2残留"，控制面板里可能看不到，这种情况我在第3.3节会说怎么清理。

Linux上，先执行：

which python2 python2 --version

• 如果which python2显示/usr/bin/python2，那基本是系统自带的。别急着删，先检查系统里哪些包依赖它。

Linux检查依赖的命令：

rpm -qR python2 2>/dev/null | head -20 # CentOS/RHEL apt-cache rdepends python2 2>/dev/null | head -20 # Ubuntu/Debian

或者直接用rpm -e模拟卸载看依赖：

rpm -e --test python2

• 如果输出一大堆"is needed by ..."，说明有系统工具依赖它，强行删除很可能导致yum或apt崩溃。相对安全的办法是保留它不动，只是把默认python指向Python 3，然后让Python 2"养老"在系统里。反正它除了占点磁盘空间，平时也不会主动出来惹事。

macOS上，系统自带的Python 2在旧版本macOS（Mojave及之前）存在于/usr/bin/python。苹果官方和社区的主流建议都是不要手动删，因为系统某些底层组件和脚本会调用它。真正想摆脱Python 2，靠的是把/usr/local/bin或pyenv里新版本放到PATH前面，让所有命令默认优先用Python 3。

3.2 Windows环境中Python 2的标准卸载与残留清理

如果你的Windows控制面板里明确看到Python 2.x，操作就简单了。

1. 先去控制面板卸载。卸载完建议重启一下电脑，让环境变量彻底刷新。
2. 检查环境变量PATH里还有没有Python 2的残留路径，比如C:\Python27和C:\Python27\Scripts。有的话就删掉，否则以后系统的where python可能会显示一个"幽灵路径"，新装的Python 3反而排到后面去，命令怎么敲都不对。

这里我要多说一句令人头疼的事：有些软件在安装时会把Python 2装到一个不显眼的位置，不经过"程序和功能"入口，而是直接写一个文件到系统里，比如旧版Golden Software、某些测绘工具、十年前的内网办公系统等。它们的特征是：控制面板里看不到Python 2，但你在cmd里敲python却会弹出Python 2的交互界面。

遇到这种情况，我的处理方式是：

• 先用where python把实际路径找出来，找到后手动审查这个目录里是哪家公司打包的Python。
• 确认是第三方软件的私有Python后，不要直接用文件夹删除，因为软件下次启动可能报错。正确做法是先去该软件设置里找有没有"自带Python"选项并关闭，或者重装该软件并选择"不安装Python组件"。
• 如果实在找不到关联软件，但你确定这个Python 2不是自己装的，备份好相关目录后删除，然后观察日常软件是否异常。注意，这属于"最后手段"，没事千万别轻易对未知来源的Python 2下手。

3.3 Linux中的"软链接替换法"：不真正卸载，却让Python 2彻底退役

很多人对"卸载"有执念，认为系统里存在Python 2就是"不干净"。但从运维角度说，有时候不卸载反而是最安全的方案。对于系统依赖Python 2的情况，我强烈推荐"替换优先路径"的做法，而不是物理删除。

以CentOS 7为例，系统自带的Python 2.7被yum和/usr/libexec/urlgrabber-ext-down依赖，删掉之后yum直接废掉。我的做法是这样。

第一步，安装Python 3后，创建自己的管理目录（按第2.2节的方式装到/usr/local/python311），这样Python 3已经在新路径下正常工作。

第二步，修改PATH变量，让新Python 3排在最前：

echo 'export PATH=/usr/local/python311/bin:$PATH' >> /etc/profile.d/python311.sh source /etc/profile.d/python311.sh

第三步，把常用的python命令软链接指向Python 3：

sudo ln -s /usr/local/python311/bin/python3.11 /usr/local/bin/python sudo ln -s /usr/local/python311/bin/pip3.11 /usr/local/bin/pip

注意，我这里没有去动/usr/bin/python，因为那是yum等系统工具的命根子。我是在/usr/local/bin里新建了python软链接，由于/usr/local/bin通常排在/usr/bin前面，终端里敲python就会走/usr/local/bin/python，也就是Python 3；而yum内部调用/usr/bin/python时，走的还是系统Python 2。

这样做的效果是——用户层面Python 2彻底"消失"了，系统层面依赖Python 2的工具依旧正常运行。既不卸载，又达成了"让Python 2退役"的目标。

Ubuntu/Debian也类似。Ubuntu 18.04及以前自带Python 2，很多系统维护命令依赖它。按上面思路，装好新的Python 3后，用update-alternatives这个机制来管理命令优先级其实更正规：

sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.11 1 sudo update-alternatives --config python

执行后可以通过选项切换默认python版本，比直接软链接更安全。Ubuntu上有些老版本的apt包管理脚本也会调python，所以不到万不得已，不去apt remove python2。

3.4 清理Python 2遗留的/Library、site-packages和PATH残余

无论是Windows还是Linux，卸载或隔离Python 2之后，都有一些"尸骸"需要手动处理。这些残留物看起来不起眼，但会时不时给你挖坑。

首先是PATH残留。如果你的PATH变量里还有C:\Python27或/usr/bin/python2之前的旧路径，命令解析就可能指向错误版本。检查并清理掉。

其次是site-packages残留。Python 2时代装的第三方库会留在对应site-packages目录里，卸载Python 2后这些目录依然存在，它们对Python 3是无效的（Python 2和3的包目录结构不同），但会占地。Windows上一般是C:\Python27\Lib\site-packages，删除整个Python 2安装目录即可；Linux上如果卸载了python2相关包，系统会清掉大部分，但编译安装的Python 2可能还留在/usr/local/lib/python2.7，手动删掉就行。

macOS上，手动安装的Python 2可能有好几个位置：/Library/Frameworks/Python.framework/Versions/2.7、/usr/local/lib/python2.7等。删除前先确认哪个是Homebrew装的、哪个是官方pkg装的。Homebrew管理的可以用brew uninstall python@2清理，pkg安装的要用pkgutil --forget org.python.Python.Python-framework-2.7这样的命令注销，否则系统"记忆"里始终认为它还在。

最后还有一样东西容易被忽略——pip缓存和配置。~/.pip/pip.conf（Linux/mac）或%APPDATA%\pip\pip.ini（Windows）里如果写了index-url等配置，新pip一样会读取，一般来说不影响。但~/.pydistutils.cfg这种老配置文件里的[install]字段可能导致Python 3的pip安装到奇怪目录，发现异常时要记得删掉。

4. 新旧版本共存期最容易踩的坑：PATH优先级、pip错乱与虚拟环境实践

4.1 "pip明明装了包，python却import不到"的经典原因

新装Python 3后，你很可能遇到这样一个奇怪问题：用pip install requests装了一个包，然后再运行python脚本，提示ModuleNotFoundError: No module named 'requests'。

我第一次遇到这问题时还以为是包没装上，查了快半小时。后来发现，pip命令和python命令指向的不是同一个Python解释器。可能pip是Python 3.11的pip，而python因为PATH优先级的原因指向了某个旧版Python 3.6，或者更倒霉——指向了残留的Python 2。

解决办法很简单：永远用"解释器+模块"方式调用pip，而不是单独敲pip命令。

python3 -m pip install requests

python3 -m pip的意思是：把pip当作Python 3.11的一个模块来运行。这样一来，pip的安装目标100%和python3解释器一致，绝对不会装错地方。这是Python生态里非常经典且安全的用法，我后来所有环境都是这么装的，再没出现过"装完却import不到"的问题。

4.2 并发使用Python 2和3时，pip的版本前缀规则

在你还没下定决心卸载Python 2的时候，系统里会同时存在两套pip。这种情况下，命令的版本对应关系一定要记牢：

表里最关键的是最后一行。很多教程都会说"用pip3装包"，但说实话，pip3也不一定安全，因为它可能被软链接指向一个你意料之外的Python 3子版本。而python3 -m pip中间不会转任何弯，最靠谱。

另外说个Windows上的小坑：有些Windows机器里可能有多个Python 3版本，微软商店版、官网版、Anaconda版各来一个。命令提示符里python到底跑哪个，完全看PATH顺序。如果你装了Anaconda又装了官网python，最好去环境变量里把不用的路径删掉，否则一定会乱。

4.3 为什么venv能在"不碰系统Python"的情况下隔离一切

有了上一节的经验，你可能会问：那我是不是可以直接建一堆venv，彻底绕开PATH带来的混乱？答案是：对，这才是正规军的玩法。

venv的原理是创建一个虚拟目录，里面会生成一个bin/python（Windows是Scripts/python.exe），并且这个Python软链接会指向你创建venv时指定的那个Python 3解释器。激活venv后，你的python和pip都被这个"局部环境"接管，不会再受系统PATH影响。

举个例子，我在同一台服务器上同时维护了两个项目：一个是数据分析平台，要求Python 3.11 + numpy 2.0；另一个是自动化运维脚本，要求Python 3.9 + numpy 1.26。如果装在全局环境，两个numpy版本必然打架。但分别建两个venv后，两个项目的依赖完全是两个封闭世界，互不干扰，进程起来后各自用各自的环境，无比清爽。

再说一个实操细节：创建venv的时候建议显式指定Python解释器，避免系统默认的python3指向不明确。

python3.11 -m venv /path/to/myproject_env

这样这个venv就铁定绑定了Python 3.11。以后哪怕系统默认Python变成了3.12，这个项目也还是按3.11跑，不会被意外升级打破兼容性。

4.4 等旧脚本全部迁移完成再卸载：一个真实的迁移检查清单

前面铺垫了这么多，现在说回正题。你什么时候才算真正可以放心卸载Python 2？我的判断标准不是"我把它卸了"，而是"我的所有工作流里已经找不到任何还依赖Python 2的环节"。

我整理了一份个人迁移检查清单，你可以照着过一遍：

1. 列出所有自己写的Python脚本，逐一确认语法兼容Python 3。重点检查print语句、/除法、xrange、unicode、StringIO、except Exception, e这类老语法。
2. 用系统工具全局搜索一下有没有#!/usr/bin/env python或#!/usr/bin/python2这样的shebang头，如果有，改成#!/usr/bin/env python3。
3. 检查crontab定时任务、CI流水线、服务启动脚本，看它们有没有写死python2或/usr/bin/python。
4. 在Python 3环境下逐一运行项目测试，确认核心函数输出一致。编码问题尤其要仔细，Python 2和3对字符串的默认处理逻辑完全不同。
5. 确认所有第三方库都有Python 3版本。这个可以直接到库的官方文档或PyPI上看Support Python Versions标签。
6. 检查有没有系统级依赖Python 2的工具会受影响。Linux下用rpm -qR python2或apt-cache rdepends python2再看看，Windows下确认控制面板里卸载后没有其他软件报错。

这份清单走完，项目层面就基本不会被Python 2拖累了。此时再卸载，或者继续让Python 2在系统里躺着不动（Linux常见做法），都不会影响你的日常开发了。

5. 实际操作中容易被忽略的异常情况与排查心得

5.1 官网下载极慢？使用国内镜像源下载安装包

很多小伙伴卡在第一步"下载安装包"———官网服务器在国外，有时下载速度令人绝望。这里有个实用技巧。

如果你想下载Python安装包，可以把下载地址的域名替换成国内镜像。以华为云镜像为例，下载链接结构是：

https://mirrors.huaweicloud.com/python/3.11.0/Python-3.11.0.tgz

这样下载Linux源码包会快出天际。Windows安装包（.exe）也一样，去找国内Python镜像的windows目录即可。另外下载时注意对比一下文件大小，官网页面通常每版都会标注源码包大小，如果下载下来小很多，很可能是被截断了，这种包装到一半会报错。

5.2 "python was not found; run without arguments to install from the Microsoft Store"是Windows独有的提示

不少人刚在Windows官网装完Python 3，打开cmd一敲python，却弹出这样一句提示：

python was not found; run without arguments to install from the Microsoft Store

这不是报错，也不是你没装好。这是Windows的应用执行别名（App Execution Aliases）在捣鬼。Windows商店会注册两个名为python.exe和python3.exe的"假命令"，当你没有关闭商店版别名、且PATH里Python路径没排到前面时，cmd就会撞上这两个假入口。

解决办法有两种：

1. 直接到"设置 -> 应用 -> 高级应用设置 -> 应用执行别名"，把python.exe和python3.exe两个开关关闭。这是最彻底的解法。
2. 在环境变量里把Python 3.11的路径和Scripts路径上移到PATH最顶部，让真正的Python 3先被找到。

我记得第一次遇到这个提示时一度以为电脑上Python没装成功，后来仔细研究才发现是那个"Microsoft Store版占位符"的问题。如果你也遇到，按上面两步处理就行。

5.3 卸载Python 2后，控制台输入python没反应或提示找不到命令

Windows上卸载Python 2后再敲python提示"不是内部或外部命令"，这种情况大概率是PATH里Python 2路径被删掉了，同时Python 3的路径又没有正确添加进来。

此时打开"环境变量"（系统属性 -> 环境变量 -> Path -> 编辑），检查有没有Python 3安装目录和Scripts目录。没有就手动新增两条：

D:\Python311 D:\Python311\Scripts

然后新开一个cmd窗口（注意：必须新开窗口，旧窗口的环境变量不会自动刷新），再验证python --version。

Linux上如果python突然"找不到命令"，检查一下是不是前面用软链接创建/usr/local/bin/python那一步没操作成功，或者/usr/local/bin不在PATH里。执行echo $PATH看看，如果没有/usr/local/bin，把它加到PATH最前面即可。

5.4 "cc攻击源码"等奇怪热词背后的真实需求：不要尝试这些脚本

我在整理这篇内容时看到搜索热词里有"python cc攻击源码"这类词，必须多说一句。这里说的"CC攻击"本质是利用大量请求占用服务器资源的网络攻击行为，在多数国家和地区都是违反法律法规的行为。用Python写这类攻击脚本没有任何建设性价值，只会给自己惹麻烦。带着好奇心学习Python可以，但请把精力放在正经方向上：爬虫、数据分析、自动化办公、量化交易策略回测、机器学习，这些方向远比研究攻击代码有价值。看到这类"源码"，直接跳过就好。

5.5 编码问题是最容易让旧脚本在Python 3下崩溃的隐形杀手

Python 2时代，字符串str是字节串，unicode才是文本；Python 3里str直接就是文本，底层编码统一用Unicode。这就导致一个典型现象：同一段处理中文字符串的代码，在Python 2下运行正常，迁移到Python 3后经常出现UnicodeDecodeError或输出乱码。

有一次我迁移一个抓取网页标题的脚本，Python 2下跑得好好的，切到Python 3怎么都报错。查了半天发现是原来的代码里到处是# -*- coding: utf-8 -*-声明，但处理时却用decode('gbk')把字节流强转成GBK——Python 3下这类"多余的解码"反而把正常的Unicode文本搞乱了。

我的经验是：迁移到Python 3后，只要明确数据是文本，就不要随便调用decode/encode，让Python的str类型自己处理编码。用requests抓网页时，res.text通常已经根据HTTP头正确解码了；res.content才是原始字节流。能用text的绝不强行处理content。

6. 一套完整的"新环境初始化"操作流程建议

讲了这么多零散的坑，最后给大家整理一个我自己在新电脑或新服务器上初始化Python环境的完整流程。这套流程经过了多次服务器和笔记本的验证，照着做基本不会出问题。

1. 安装Python 3：根据平台选择第2节的方式，Windows用官网安装包并勾选PATH，Linux用包管理器或源码编译，macOS用pyenv。
2. 验证安装：确认python3 --version输出正确，确认python3 -m pip --version可用。
3. 清理PATH：检查系统PATH里有没有旧Python路径，确保新Python路径优先。
4. 处理Python 2：判断是系统依赖还是独立安装，Linux优先用"替换优先路径"而非卸载；Windows如果没依赖，可以正常卸载并清理残留。
5. 创建项目专用venv：

   python3.11 -m venv ~/venv/myproject source ~/venv/myproject/bin/activate

6. 在venv内安装依赖：

   pip install --upgrade pip pip install -r requirements.txt

7. 建立pip国内镜像配置（推荐，大幅提升下载速度）。在用户目录下创建~/.pip/pip.conf（Linux/mac）或%APPDATA%\pip\pip.ini（Windows）：

   [global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple trusted-host = pypi.tuna.tsinghua.edu.cn

8. 测试项目脚本：运行一遍核心脚本，确认依赖、编码、路径都没有问题。
9. 记录版本信息：执行下面命令，把环境信息写进项目的README或文档里：

   python --version pip list

这套流程的核心理念就一句话：先用新版本把自己的工作流跑顺，再去考虑旧版本的卸载。在没有完全迁移之前，"Python 2卸载"这件事可以无限期延后，反正只要PATH优先级控制好，Python 2躺在系统里也不会造成任何影响。

我在实际操作中的体会是，很多人折腾Python版本，用力过猛反而把环境搞乱，最后陷入"卸了装上、装完又卸"的循环。其实先想清楚"为什么要升级、系统里谁还在依赖旧版本、项目代码有哪些兼容点"，按部就班走一遍，一两个小时就能干净利落地搞定。