嘿，哥们儿姐们儿，写 Python 代码写得正嗨，突然崩了！或者装了个新库，死活不好使，报错信息一团糟，第一个念头是啥？十有八九得瞅瞅，自己到底用的哪个 Python？版本对不对？那库是不是装对地方了？说白了，就是得查看 Python 的各种状态信息。这事儿听着简单，但里头弯弯绕还真不少，尤其是当你系统里装了不止一个 Python，或者用了虚拟环境之后，简直能让你头大。
查看 Python 版本，这算是最基础的了吧？就像你买了个手机，总得知道它是什么型号。最直接、最野蛮的方式，就是打开你的终端、命令行界面（Windows 用户找 CMD 或者 PowerShell，macOS/Linux 用户就 Terminal 呗），然后敲这么一句：
bash
python --version
或者你也可以试试这个：
bash
python -V
注意哦，一个是双破折号 --version，一个是单破折号 -V。为啥有两种？说起来，-V 以前更常用，是缩写，但有些新版的或者不同的解释器实现可能更推荐 --version。反正，哪个好使就用哪个呗，大多数时候两个都行。敲下去，回车， Duang！一行字出来了，比如 Python 3.9.7 啥的，这就是你的 Python 版本号。
等等，你敲了 python 没反应？或者出来个 command not found？那说明你的系统压根就没找到 python 这个命令。这又牵扯到另一个问题了：你的 Python 装哪儿了？系统是怎么知道去哪儿找它的？这就要讲到 查看 Python 解释器路径 了。
你想知道你敲下的那个 python 命令，它背后对应的是硬盘上的哪个具体文件吗？就像你喊一个人名字，想知道他现在站在哪儿。在 macOS 和 Linux 上，有个特别好用的命令叫 which。
bash
which python
它会告诉你执行文件在文件系统里的完整路径，可能是 /usr/local/bin/python 也可能是别的什么。看到这个路径，你就知道系统默认调用的 Python 解释器到底藏在哪儿了。
Windows 用户呢？别急，Windows 也有类似的，不过命令名字不一样，叫 where。
bash
where python
敲这个，它可能会列出不止一个路径！这事儿就复杂了。为啥会列出多个？因为 Windows 的环境变量 PATH 里可能有好几个指向 Python 的地方。系统会按照 PATH 变量里路径的顺序，找到第一个能执行的 python.exe 就用它。所以，即使你装了 Python 3.10，但如果 PATH 里 Python 2.7 的路径排在前面，你敲 python 出来的还是 2.7！这可是多少新手甚至老手都踩过的坑啊！所以，查看 Python 解释器路径 不仅告诉你它在哪，有时更能帮你理解为啥运行结果和你预想的不一样。
光知道 Python 解释器在哪儿还不够，很多时候我们更关心的是，某个特定的库（比如 requests、numpy、pandas）我装好了吗？装的是哪个版本？这些库文件又在哪里？这时候，查看某个库的版本 就成了日常操作。
如果你是用 pip 安装和管理库的，那么 pip show 命令简直是你的好朋友。
bash
pip show requests
敲下这个，pip 会给你一堆关于 requests 库的信息：Version、Location、License、Requires（它依赖哪些库）、Required-by（哪些库依赖它）等等。最直接的就是那个 Version，一下就告诉你装的是 requests 的哪个版本。那个 Location 也很有用，它告诉你这个库具体安装在你系统（或虚拟环境）的哪个目录里。有时候排查 ModuleNotFoundError 的问题，看一眼这个 Location，再对照你的 sys.path（后面会讲到），基本就知道是不是 Python 解释器没找到这个库文件了。
除了 pip show，还有一种方法，更像是直接问问正在运行的 Python ：“喂，你引用的这个库，它说自己是哪个版本？” 这需要在 Python 的交互环境里或者在你的脚本里来做。
python
import requests
print(requests.__version__)
打开 Python 交互模式（直接在终端敲 python 回车就行），或者在你脚本里加上这两行，运行一下。如果 requests 库存在，并且它规范地定义了 __version__ 这个属性（大多数流行的库都会），它就会把自己的版本号打印出来。这个方法的好处是，它告诉你的是当前这个 Python 解释器实际加载并使用的 requests 版本，有时候比 pip show 更能反映真实运行时的状态，尤其是当你系统里有好几个 Python 环境的时候。
说起来，既然提到了环境，就不得不聊聊 Python 的环境变量，特别是那个神秘的 PATH。前面说了，PATH 环境变量决定了你在命令行里敲命令时，系统会去哪些目录里找这个命令对应的可执行文件。你的 Python 解释器 (python.exe 或 python3) 能不能直接敲名字运行，就看它的路径在不在 PATH 里。
怎么看你的 PATH 环境变量呢？不同系统命令又不一样。
在 Windows 上：
bash
echo %PATH%
在 macOS/Linux 上：
bash
echo $PATH
这命令会输出一长串目录路径，它们之间用分号（Windows）或冒号（macOS/Linux）隔开。系统查找命令的顺序就是按照这个列表从左往右。如果你发现你装的 Python 3.9 路径在列表很后面，前面还有个 Python 2.7 的路径，那么敲 python 出来的就是 2.7 了。解决办法通常是调整 PATH 变量里路径的顺序，把你想用的 Python 版本对应的目录移到前面，或者直接用完整路径来执行，比如 C:\Python39\python.exe your_script.py。
除了系统层面的 PATH 环境变量，Python 自己内部也有一个查找模块的路径列表，叫做 sys.path。当你写了 import some_module 时，Python 就会按照 sys.path 列表里的目录顺序，挨个儿去找 some_module.py 或者 some_module 文件夹。
怎么看 sys.path 呢？只能在 Python 里面看：
python
import sys
print(sys.path)
这会输出一个列表，里面是一堆目录路径。这些路径通常包括了：你的当前工作目录、Python 安装目录下的 site-packages 目录（pip 安装的库默认就在这儿），以及一些其他的标准库路径。如果 pip show 告诉你某个库装在某个目录，但那个目录不在 sys.path 里，那么 import 这个库的时候就会失败。理解 sys.path 对于解决 ModuleNotFoundError 至关重要。
最后，虚拟环境这玩意儿，现在简直是 Python 开发的标配。无论是 venv、virtualenv 还是 conda，它们的核心思想都是创建一个独立、隔离的 Python 环境。在这个环境里安装库，不会影响到系统全局或其他虚拟环境。这极大地避免了版本冲突的问题。
怎么知道你当前是不是在一个虚拟环境里？最直观的标志通常是你的命令行提示符会变。比如，如果你用 venv 激活了一个叫 myenv 的虚拟环境，你的提示符前面可能会多出 (myenv) 这样的字样。看到这个，你就知道你现在不是在“裸奔”了，而是在一个特定的沙盒里。
进入虚拟环境后，你再用前面提到的方法去查看 Python 版本 (python --version)、查看解释器路径 (which python 或 where python)、查看库版本 (pip show)、查看 sys.path (import sys; print(sys.path))，它们显示的结果都会是当前这个虚拟环境的状态，而不是系统全局的状态。比如，在虚拟环境里 which python 可能会指向虚拟环境目录下的一个路径，而不是系统 /usr/local/bin 里的。在虚拟环境里 pip show requests 也只会告诉你这个虚拟环境里安装的 requests 版本。
所以说，怎么查看 python 这事儿，远不止敲个 python --version 那么简单。它其实涵盖了理解你用的 Python 解释器是哪个、它在哪、它能找到哪些库、这些库都是啥版本，甚至你是不是在一个隔离的环境里工作。这些看似琐碎的信息，串起来就是你整个 Python 开发环境的骨架。摸清楚这些，遇到问题时就不会抓瞎，能更快定位到是版本不兼容、路径不对，还是环境混乱。这过程就像给你的 Python 生态系统做体检，看着麻烦点儿，但理顺了，后续的开发才能更顺畅，少掉头发！
评论(0)