python和python3命令区别为什么有两个

沿途有光

发布时间：2026-11-13| 7人浏览过

原创

深入解析终端中 python 与 python3 命令的核心区别、存在两个命令的历史背景（PEP 394 规范）、操作系统软链接与 PATH 解析机制，并提供跨平台排查步骤与现代开发工程最佳实践。

在终端中之所以同时存在 python 与 python3 两个命令，核心原因在于 Python 2 到 Python 3 的重大不兼容版本演进历史，以及 Python 官方为了防止系统级底层依赖崩溃而制定的 PEP 394 规范。python3 始终严格指向 Python 3.x 解释器，而 python 命令在历史上曾固定代表 Python 2.x，在现代操作系统中则可能指向 Python 3.x、未安装、或由活跃的虚拟环境动态接管。

图 0：终端双命令概览与核心特性对比卡片

一、为什么会有两个命令？背后的历史演进与 PEP 394 规范

很多开发者在刚开始接触编程时，往往会有这样一个疑问：既然安装了 Python，为什么终端里有时输入 python 能运行，有时又必须输入 python3？为什么开发团队不直接保留一个统一的名字？

要理解这一现象，首先必须回顾 Python 语言历史上的分水岭——2008 年底发布的 Python 3.0。与常见的软件小版本升级不同，Python 3 是一个故意放弃向后兼容性（Backward Compatibility）的大版本改造。它彻底修正了早期版本中混乱的编码模型（全面采用 Unicode 字符串并分离 bytes 二进制）、将 print 从关键字变为函数、修改了整数除法逻辑并重构了大量标准库结构。这意味着：绝大多数未经修改的 Python 2 脚本，直接扔给 Python 3 解释器执行时会当场报错崩溃。

在当时，几乎所有的 Linux 发行版（如 Ubuntu、CentOS）以及 macOS，系统底层都极度依赖 Python 2。例如 Linux 的包管理器（如 yum/dnf）、系统自动化管理脚本、桌面环境驱动程序等，都是用 Python 2 编写的。如果操作系统在用户升级时直接将原有的 python 命令无缝替换为 Python 3，那么操作系统的包管理器和各类关键后台服务会瞬间全面瘫痪。

为了解决这一严重的过渡冲突，Python 社区于 2011 年正式发布了 PEP 394（The "python" Command on Unix-Like Systems，类 Unix 系统上的 python 命令规范）。该规范明确给出了推荐原则：

python2 命令：必须严格指向某个 Python 2 版本的解释器（目前该版本已于 2020 年正式 EOL 停更退役）。
python3 命令：必须严格指向某个 Python 3 版本的解释器。
python 命令：在过渡期建议由发行版自主裁量。旧规范建议指向 Python 2，避免破坏老脚本；随着 Python 2 彻底退出历史舞台，新版 PEP 394 修正建议：python 可以指向 Python 3，或者干脆默认不提供该命令，强迫开发者在脚本头部与终端中显式声明 python3。

二、底层机制：Shell 如何通过 PATH 和符号链接定位这两个命令

在类 Unix 系统（包括 macOS 和各类 Linux）中，你在终端输入的每一个命令本质上并不是操作系统内核的魔术，而是一个基于环境变量的查找过程。

当你在终端输入 python3 并敲击回车时，Shell（如 bash 或 zsh）会依次读取环境变量 $PATH 中记录的各个目录（例如 /usr/local/bin、/usr/bin、/bin 等）。一旦在某个目录中首次找到了名为 python3 的可执行文件，Shell 就立即停止搜索并执行它。

而找到的这个文件，通常不是一个几十兆的巨大二进制文件，而是一个轻量的符号链接（Symbolic Link，软链接）。例如，/usr/bin/python3 往往只是一个指针，指向系统真正编译安装的实体文件，如 /usr/bin/python3.10。如果系统中安装了提供兼容性的宏包，/usr/bin/python 也会作为一个软链接，指向 python3。

图 1：Shell 环境变量 PATH 检索机制与符号链接多级映射拓扑

如图 1 所示，双命令的存在实际上构筑了一个灵活的“多级路由机制”。在同一台机器上，系统维护者可以通过软链接保持底层工具调用 python3 的稳定性，而上层用户也可以通过修改 PATH 变量或激活虚拟环境，让 python 指向项目专用的解释器。

三、排查与确认：4 步定位你电脑上两个命令的真实指向

因为不同操作系统、不同版本甚至不同的安装方式（官方安装包、Homebrew、apt、Anaconda 等）会让命令指向完全不同，因此当你遇到脚本运行异常或模块找不到时，切忌盲目猜测。请按照以下 4 个步骤在终端中逐步排查。

步骤 1：检查版本号，确认大版本归属

首先分别查看两个命令所汇报的具体版本号。注意一定要使用大写的 -V 或双横线 --version。

执行命令示例

python -V
python3 -V

常见输出对比（示例）

# 场景 A：现代正常环境（二者均指向 Python 3）
$ python -V
Python 3.11.8
$ python3 -V
Python 3.11.8

# 场景 B：未配置 python 别名的纯净环境
$ python -V
zsh: command not found: python
$ python3 -V
Python 3.10.12

# 场景 C：旧款系统残留 Python 2
$ python -V
Python 2.7.18
$ python3 -V
Python 3.9.6

如果你的电脑输出类似场景 C，说明输入 python 会唤醒已经废弃的 Python 2，在日常开发中绝对不能使用 python 命令。

步骤 2：使用 which 命令定位可执行文件所在路径

在 Linux 或 macOS 终端中执行 which（Windows 下使用 where），可以快速查明 Shell 到底执行了 PATH 中的哪一个文件：

执行命令示例

which python
which python3

常见输出对比（示例）

$ which python3
/opt/homebrew/bin/python3

$ which python
/usr/bin/python

从输出可以清楚看到：python3 来自 Homebrew 用户安装目录，而 python 可能是系统自带的占位程序。路径不同意味着它们读取的第三方库和运行时环境互不相通。

步骤 3：查看符号链接的目标文件（穿透快捷方式）

通过 ls -l 或 readlink 可以一层层揭开软链接的真实去向：

执行命令示例

ls -l $(which python3)
readlink -f $(which python3)

常见输出对比（示例）

$ ls -l /usr/bin/python3
lrwxrwxrwx 1 root root 10 Jun 2 2023 /usr/bin/python3 -> python3.10

步骤 4：在解释器内部直接打印可执行文件属性

如果你想 100% 确认代码在运行时究竟是在哪个 Python 环境中跑起来的，最具权威的方法是直接向解释器索取其内部内置变量：

执行命令示例

python3 -c "import sys; print(sys.executable)"

输出示例

/Library/Frameworks/Python.framework/Versions/3.12/bin/python3

这一行输出是 Python 进程内部的绝对路径，任何外部环境变量别名或 alias 伪装都无法欺骗这个变量。

图 2：排查与验证 Python 命令指向的 4 步标准操作流程

四、三大平台行为差异：macOS、Linux 与 Windows 的差异细节

不同操作系统对这两个命令的管理哲学各不相同。了解你所处操作系统的特有机制，能够避免许多配置踩坑。

平台类型	python 命令默认行为	python3 命令默认行为	主流管理建议
macOS (12.3 Monterey 之后)	已被彻底移除，调用可能提示安装 Xcode 命令行工具	由 Xcode CLT 或 Homebrew 提供	始终输入 `python3`；严禁手动污染系统路径
Ubuntu / Debian	默认无该命令（Command not found）	系统核心内置，维护系统基础组件	可选安装官方包 `python-is-python3` 建立别名
Windows 10/11	默认跳转微软商店，安装后由安装包生成 python.exe	部分版本提供 store stub 引导	推荐优先使用官方 Python 启动器：`py`

针对 Ubuntu / Debian 用户的实用提示

如果你在 Ubuntu 上运行很多老教程的脚本，每次输入 python 都提示找不到命令，不要随意手动执行 sudo ln -s /usr/bin/python3 /usr/bin/python。官方提供了合规的过渡软件包，只需运行：

sudo apt update && sudo apt install python-is-python3

该包会按照 Debian 规范安全建立软链接，并且在后续系统升级时受到官方包管理器妥善维护。

针对 Windows 用户的特别提醒

Windows 在安装 Python 官方安装包时，默认只会生成 python.exe，并不一定会提供 python3.exe。但 Windows 安装包附带了非常强大的 Python Launcher（py.exe）。在 Windows CMD 或 PowerShell 中，推荐使用 py -3 script.py 或直接输入 py 进入交互环境，它会自动查找机器上安装的最新 3.x 解释器。

图 3：macOS、Linux、Windows 平台上的命令机制与行为对比矩阵

五、最容易踩坑的衍生问题：pip 与 pip3 的连锁反应

双命令机制引发的最普遍、破坏力最大的问题，莫过于第三方包管理工具 pip 的版本错位。

很多开发者在终端中敲下：

常见混淆操作示例

pip install requests
python3 main.py

结果在运行代码时，终端却抛出令人抓狂的异常：ModuleNotFoundError: No module named 'requests'。

之所以会这样，是因为独立的 pip 命令文件本身也是一个 Python 脚本。它的首行（Shebang）硬编码绑定了特定的解释器路径。如果你的系统里曾经安装过残留的 Python 2 或者另一个版本的 Python 3，那么输入 pip 很可能会把库安装到了一个你完全没有运行的 Python 目录下！

工程防错铁律：永远通过解释器模块方式调用 pip

为了从根本上切断 pip 与 Python 解释器之间的错位，现代工程中强烈推荐永远不要直接调用独立的 pip 命令，而是显式通过解释器以模块方式运行：

python3 -m pip install <package_name>

这种写法的意思是：“使用明确的 python3 解释器，并启动其内部绑定的 pip 模块去安装依赖”。这样无论系统 PATH 里有多少个混乱的 pip 脚本，安装的包都 100% 会落入当前 python3 的 site-packages 目录中。

六、现代工程最佳实践与决策指南

在实际团队协作和生产部署中，我们应当如何规范使用这两个命令？请遵循以下三条工程准则：

在系统全局环境中，一律显式键入 python3：
只要你没有激活虚拟环境，在任何脚本、文档或交互调试中，都明确键入 python3。这不仅能避免误触旧环境，更能够让脚本拥有极佳的跨机可移植性。
为每个项目创建独立的虚拟环境（venv）：
在项目根目录下通过 python3 -m venv .venv 创建虚拟环境。一旦执行了 source .venv/bin/activate（Windows 为 .venv\Scriptsctivate），虚拟环境会自动修改当前 Shell 会话的 PATH，把 .venv/bin 提到第一位。在此状态下，输入 python 与 python3 将完全等价，均安全指向项目沙箱内的解释器。
编写可执行脚本时使用规范的 Shebang 首行：
在编写独立的 Python 脚本时，首行应声明：
#!/usr/bin/env python3
使用 /usr/bin/env python3 能够让系统自动沿当前会话的 PATH 寻找首选的 Python 3 解释器，既兼容虚拟环境，又符合 PEP 394 标准。

图 4：现代 Python 开发中的命令选择与工程决策指南

总结：系统之所以同时存在 python 和 python3，不是设计缺陷，而是为了在平稳过渡 Python 2 到 3 历史包袱时保护操作系统而诞生的工业妥协。在今天的开发环境中，牢记“全局显式使用 python3，项目内部使用 venv，模块方式运行 pip”，即可彻底远离版本混淆与环境冲突的困扰。