Python 虚拟环境乱了，先看 pip 装到了哪个解释器

装了一个包，运行却提示找不到模块，这种情况多半不是包没装，而是装到了另一个解释器名下。Python 环境一多，系统自带、手动安装、虚拟环境里的解释器很容易混在一起，pip 和 python 若不是同一套，装与用就会错位。

先对齐两个命令

在终端里先看两个命令到底指向哪里。which python 与 which pip 若路径不一致，后面所有排查都要先停下来。更稳妥的办法，是用 python -m pip 来装包，这样装包动作一定发生在当前 python 名下，不再依赖 pip 这个独立命令的指向。同样，运行脚本时也尽量写清楚用哪一个解释器，而不是只凭 python 这个名字猜。

虚拟环境激活后，命令提示符前面通常会出现环境名，这是一个信号，但不是保证。激活脚本只改当前 shell 的路径顺序，换一个终端窗口、换一个脚本运行方式，环境就可能又回到系统默认。所以每次排错，先在当前窗口里确认一次，而不是凭上一次的记忆断定。

包到底装进了哪里

用 pip list 只能看到当前 pip 名下的包，看不到另一个解释器里的情况。更直接的是看包的安装位置：pip show 加上包名，会列出 Location 字段，把它和当前解释器的 site-packages 路径对照，就能判断是不是装错了地方。也可以在代码里打印 sys.executable 与 sys.path，前者是真正跑起来的解释器，后者是它找模块的目录清单，模块若不在这些目录里，提示找不到就是必然的。

还有一种常见情形：项目里有多个虚拟环境，旧环境的包很全，新环境却是空的。打开项目后先确认编辑器或运行配置选的是哪一个环境，编辑器里显示的解释器路径与终端里用的路径不一致时，代码提示正常、终端运行报错，或者反过来，都会出现。

依赖装好了，版本却不对

装对了解释器，仍可能遇到版本问题。有的包对 Python 版本有要求，有的包互相要求对方的特定版本范围，装完一个，另一个被悄悄升级或降级，运行时才暴露冲突。装包前看一眼项目里的 requirements 文件或锁定文件，尽量按文件里的版本装，而不是每次都装最新版。已经乱了的时候，先把出问题的包单独列出来，看它的版本与报错里提到的版本是否一致，再决定是升级、降级还是换一个兼容版本。

系统级解释器尽量不要直接往里面装项目依赖。系统工具可能依赖系统 Python 的特定包，往里面装包或升级包，有可能影响系统工具。项目依赖放进虚拟环境，是成本最低的隔离方式，出问题删掉重建一个环境即可，不会牵连系统。

一套不容易乱的习惯

新建项目时先建虚拟环境，再装依赖，依赖确定后随手记下版本清单。运行与装包固定用 python -m pip 与明确的解释器路径。换机器或换同事接手时，先按版本清单重建环境，而不是把旧环境的包目录整个拷贝过去。目录拷贝看似省事，路径与编译产物可能已经对不上新机器，反而埋下更难查的问题。

遇到找不到模块，先别急着重装。按顺序问三个问题：现在跑的是哪个解释器，包被装到了哪个解释器，版本是不是项目要的版本。多数情况下，答案就在这三问里，重装只是把错位再重复一遍。