本文详解 Ubuntu 20.04 下使用 python3 -m venv 创建的虚拟环境中 Jupyter 启动报错（如 ModuleNotFoundError: No module named 'jupyterlab'）的根本原因，指出命令误用、路径污染与内核依赖冲突三大症结，并提供可复现的验证步骤与工程级修复方案。

本文详解 ubuntu 20.04 下使用 `python3 -m venv` 创建的虚拟环境中 jupyter 启动报错（如 `modulenotfounderror: no module named 'jupyterlab'`）的根本原因，指出命令误用、路径污染与内核依赖冲突三大症结，并提供可复现的验证步骤与工程级修复方案。

你遇到的错误看似是模块缺失，实则是环境隔离失效 + 命令解析路径错位共同导致的典型陷阱。关键线索已在你的诊断中浮现：which jupyter 明确返回了虚拟环境内的可执行文件 /home/della/.../.venv/bin/jupyter，但实际执行时却加载了系统级或用户级（~/.local/）的 notebook 包——这直接违背了 venv 的设计初衷。

? 根本原因分析

1. jupyter-notebook（带连字符）是已废弃的旧式调用方式
   自 Jupyter 5.0 起，官方统一使用 jupyter notebook（空格分隔），而 jupyter-notebook 会被 shell 解析为独立命令名，可能匹配到系统 PATH 中其他位置（如 ~/.local/bin/jupyter-notebook）的残留脚本，该脚本依赖全局安装的 jupyterlab，从而触发 ModuleNotFoundError。你执行 jupyter-notebook 时，根本未进入 .venv/bin/ 下的入口，而是调用了外部污染路径。

2. PATH 污染：~/.local/bin 优先级高于 venv/bin
   即使你已激活虚拟环境，若 ~/.local/bin 出现在 $PATH 中且位置靠前（常见于 pip install --user 后未清理），shell 仍会优先查找该目录下的 jupyter 可执行文件。而该文件通常由 jupyter-core 安装，其内部逻辑可能动态导入 notebook 或 jupyterlab，但这些包并未在你的 venv 中安装（或版本不兼容）。

3. 依赖链隐式耦合：notebook 包间接依赖 jupyterlab
   你的 pip_requirements.txt 同时声明了 jupyterlab 和 notebook，但 notebook>=7.0 版本开始，其 app.py 确实引入了 jupyterlab.commands（用于兼容性支持）。若 jupyterlab 未被正确安装到当前 venv，或安装版本与 notebook 不匹配，就会触发该异常——这正是你看到的 traceback 根源。

✅ 正确操作流程（确保纯净 venv）

1. 彻底清理污染路径

# 检查是否意外存在全局 jupyter 可执行文件
ls -l ~/.local/bin/jupyter*
# 若存在，安全移除（仅当确认非必需时）
rm -f ~/.local/bin/jupyter* ~/.local/bin/ipython*

# 验证 PATH 顺序：venv/bin 必须在最前
echo $PATH | tr ':' '\n' | head -5
# 输出应类似：/home/della/.../.venv/bin:/usr/local/bin:/usr/bin:...

2. 在激活状态下重装 Jupyter 生态（关键！）

# 确保已激活 venv
source .venv/bin/activate

# 清理可能的残留（强制重装核心组件）
pip uninstall -y jupyter jupyterlab notebook ipykernel ipython

# 严格按依赖顺序安装（避免版本冲突）
pip install --no-cache-dir ipython ipykernel
python -m ipykernel install --user --name email-classification --display-name "Python (email-classification)"

pip install --no-cache-dir notebook  # 先装 notebook（基础服务）
pip install --no-cache-dir jupyterlab  # 再装 lab（可选，但需匹配 notebook 版本）

? 提示：jupyterlab 并非 notebook 的运行必需项，但现代 notebook 包（≥7.x）为向后兼容会尝试导入它。若只需经典 Notebook，可改用 pip install "notebook<7"（如 notebook==6.5.4），彻底规避此依赖。

Python venv 3.14.2

Python venv 3.14.2 使用 Python 3.14.2 Windows 64 位官方安装包，安装 Python 后即可使用标准库 venv 创建虚拟环境。

下载

3. 验证执行入口与环境一致性

# 确认 jupyter 命令指向 venv 内部
which jupyter
# 应输出：/home/della/.../.venv/bin/jupyter

# 直接通过 Python 模块方式启动（绕过 shell 查找，100% 确保环境纯净）
python -m notebook --no-browser --port=8888
# 成功日志将显示：[I] Serving notebooks from local directory...

# 或检查已安装包是否全在 venv 中
pip list | grep -E "(jupyter|notebook|jupyterlab)"

⚠️ 注意事项与最佳实践

• 永远使用 jupyter notebook（空格）：jupyter-notebook 是历史遗留别名，已被弃用且行为不可控。
• 避免混用 --user 与 venv：pip install --user 会污染用户级环境，与 venv 的隔离目标相悖；所有包必须通过 pip install（在激活状态下）安装到 venv。
• 内核注册需显式指定 --user 或 --sys-prefix：python -m ipykernel install --user 将内核写入用户目录（全局可见），而 --sys-prefix 写入当前 venv（推荐）。若需多环境隔离，请用后者：

  python -m ipykernel install --sys-prefix --name email-classification --display-name "Python (email-classification)"

• 升级 pip 与 setuptools：旧版 pip（如你使用的 20.0.2）可能存在依赖解析缺陷，激活 venv 后立即执行：

  pip install --upgrade pip setuptools wheel

? 总结

Jupyter 在 venv 中启动失败，本质是开发环境“表面隔离”与“实际执行路径”脱节所致。解决的关键不在于盲目重装，而在于：
✅ 明确命令规范（jupyter notebook ≠ jupyter-notebook）
✅ 切断外部 PATH 干扰（清理 ~/.local/bin）
✅ 验证执行入口归属（which jupyter 必须指向 venv/bin）
✅ 控制依赖安装粒度（必要时降级 notebook 或显式约束 jupyterlab 版本）

完成上述步骤后，你的 jupyter notebook 将完全运行在纯净的 .venv 环境中，所有依赖均来自该沙盒，彻底规避跨环境模块冲突问题。