pip list显示包却import失败，根本原因是Python解释器与pip环境不一致：需用which python（macOS/Linux）或where python（Windows）比对sys.executable路径，不一致则须在VSCode中Ctrl+Shift+P→Python: Select Interpreter重新选择带完整路径的解释器。
为什么 pip list 显示的包和 import 不上？
这通常不是 pip 坏了，而是当前 Python 解释器根本没在你认为的那个 venv 里。最直接的验证方式是运行：which python（macOS/Linux）或 where python（Windows），再对比你项目中 venv/Scripts/python.exe 或 venv/bin/python 的实际路径。两者不一致，说明环境没激活，或者 VSCode、IDE 没选对解释器。
常见干扰源包括：
- 终端已关闭，但 VSCode 终端未重启 → 旧 shell 环境残留
- 在 conda 环境下执行
python -m venv→ 新建的 venv 实际复用 conda 的 Python 二进制，版本被“继承”（比如 conda 是 3.7，但 requirements.txt 要求 numpy==1.24，pip 就会静默跳过） -
PYTHONPATH环境变量被手动设置过 → 强制 Python 加载非当前环境的 site-packages
pyvenv.cfg 中的 home 路径写错会怎样？
这个文件在 venv/pyvenv.cfg，里面 home= 这一行必须指向该 venv 所依赖的真实 Python 解释器路径。如果它错误地指向了系统 Python、Anaconda 或其他已卸载的 Python 目录，启动时就会报 No Python at ... —— Stable Diffusion 整合包报错就常出在这里。
正确做法是把 home 改成 venv 自带的解释器位置，例如：
立即学习“Python免费学习笔记（深入）”；
home = E:\AI\sd-webui-aki\venv\Scripts\python.exe
注意：不能填 python.exe 的上级目录，也不能填全局 Python 安装路径；必须是 venv\Scripts\（Windows）或 venv/bin/（macOS/Linux）下的可执行文件全路径。
conda 和 venv 混用时最危险的操作是什么？
在已激活的 conda 环境中，直接运行 python -m venv myenv 创建子环境。这看起来“更隔离”，实则埋雷：新 venv 的 python 可执行文件只是原 conda Python 的硬链接或符号链接，pip install 的行为完全受其 sys.version_info 约束。一旦 requirements.txt 里有 Python 版本敏感的包（如 numpy==1.24 要求 ≥3.8），而 conda 环境是 3.7，pip 就会跳过安装，且不报错、不警告。
安全边界只有一条：不用 conda 的时候，先 conda deactivate；不用 pip 的时候，别在 conda 环境里碰 venv。二者本质不兼容，强行嵌套只会让问题延迟爆发。
如何确认当前环境是否“干净”？
运行这三行命令，比看 pip list 更可靠：
python -c "import sys; print(sys.executable)"
python -c "import site; print(site.getsitepackages())"
python -c "import re; print(re.__file__)"
输出结果必须全部落在你的 venv 目录内（如 ./venv/...）。任意一个指向 ~/miniconda3/、C:\Python39\ 或 /usr/bin/，就说明当前 Python 正在加载外部环境的模块，隔离已经失效。这时候重装包没用，得先解决路径污染。
