2026 年 JupyterLab 4.6 找不到 Python 内核怎么办？

症状：JupyterLab 已经打开，但 Python 内核列表为空，或找不到项目环境。
最快解法：先确认启动 JupyterLab 的服务环境，再用目标 Python 安装并注册 ipykernel；选中内核后，还要验证 Notebook 实际使用的解释器和科研依赖。

遇到内核列表空白或缺少目标环境的学生，可以先按下面的方法区分服务和内核。
切换过 Python 环境的研究生，可用解释器检查步骤确认 Notebook 是否仍连着旧环境。
负责维护 Mac 分析环境的技术支持人员，也可以用验收清单记录修复结果。

JupyterLab 4.6 找不到 Python 内核：先分清故障在哪一层

JupyterLab 的页面能打开，只能说明网页界面和服务可用；它不代表目标 Python 环境已经注册成可选内核。Jupyter 架构中，服务负责启动独立的内核进程，Notebook 再连接到选定内核运行代码。(jupyterlab.readthedocs.io)

截至 2026 年 11 月 4 日，JupyterLab 官方稳定文档标示为 4.6.5。本文聚焦 4.6 系列的 Python 内核排查；实际环境中的版本以你安装的版本为准。(jupyterlab.readthedocs.io)

先记录以下信息，避免在错误的环境里反复安装：

JupyterLab 的版本，以及启动它的命令和终端。
服务运行在哪台 Mac、由哪个用户启动。
项目使用的虚拟环境路径，以及它是否刚被移动或重建。
内核列表是完全没有 Python，还是只缺少某个项目环境。
Notebook 当前显示的内核名称，以及是否能执行代码。

JupyterLab 能打开，但内核列表没有 Python，该从哪里查？
先在启动 JupyterLab 的同一个终端、同一台主机和同一用户下检查。若服务实际由另一个环境或远程主机启动，在本地终端注册的内核不一定对它可见。Jupyter Server 可用 jupyter --paths 查看搜索路径；路径不同，常常意味着检查范围也不同。(jupyter-server.readthedocs.io)

内核列表为空时，先核对服务能发现什么

在 JupyterLab 所在的服务环境中运行：

jupyter lab --version
which jupyter
jupyter --paths
jupyter kernelspec list

重点看最后两条命令：jupyter --paths 显示服务相关的数据搜索位置，jupyter kernelspec list 则列出当前 Jupyter 命令能发现的内核及其位置。内核列表既可能来自用户级目录，也可能来自环境或系统目录；macOS 的用户级目录和环境级目录并不必然相同。(jupyter-client.readthedocs.io)

如果列表中没有任何 Python 内核，先确认服务环境是否能找到基础 Python 内核。如果有其他 Python 内核、唯独没有项目环境，通常应优先检查目标环境里的 ipykernel 和注册记录，而不是重装整个 JupyterLab。

看到的表现	优先检查	下一步判断
内核列表没有任何 Python 项	服务启动环境、`jupyter kernelspec list` 的结果	服务进程是否与当前检查的 Jupyter 命令来自同一环境
能看到其他 Python 内核，但缺少项目环境	目标环境中的 `ipykernel`、kernelspec 位置	是否在目标 Python 中安装并注册了内核
能选中项目内核，但导入包失败	Notebook 的解释器路径和依赖安装位置	当前内核是否指向项目实际使用的 Python
注册过内核，启动时失败	kernelspec 中的启动路径、环境是否移动	该路径对应的 Python 是否仍存在并可运行

这里有个容易误判的点：在终端执行 python 能启动，不等于 JupyterLab 已经发现这个 Python。终端中的 python 受当前路径和激活环境影响；JupyterLab 的可选内核则依赖服务能发现的 kernelspec。jupyter kernelspec list 能列出名称和位置，但名称本身不是解释器路径的证明。(jupyter-client.readthedocs.io)

虚拟环境已装 ipykernel，列表仍没有目标环境

常见原因是 ipykernel 装在了另一个 Python 环境里。激活项目环境后，用该环境的 python 执行安装和注册命令：

# 先激活项目虚拟环境；按实际目录替换
source .venv/bin/activate

python -c "import sys; print(sys.executable)"
python -m pip install ipykernel
python -m ipykernel install --user --name research-project --display-name "Python（科研项目）"
jupyter kernelspec list

如果不想依赖激活状态，可直接用虚拟环境里的解释器执行：

/path/to/project-env/bin/python -m pip install ipykernel
/path/to/project-env/bin/python -m ipykernel install --user --name research-project --display-name "Python（科研项目）"

IPython 官方安装说明要求在目标 Python 环境中安装 ipykernel，再运行 ipykernel install 注册内核。--name 是内部使用的标识，--display-name 是界面中显示的名称；即使显示名写成“Python（科研项目）”，也要再核对它实际指向哪个解释器。(ipython.readthedocs.io)

更换 Python 环境后，怎样让旧 Notebook 使用新内核？
先在新环境中完成注册，再回到旧 Notebook 的内核选择菜单，选择对应的新显示名称。不要仅修改 Notebook 文件名或显示名称来“迁移”环境。虚拟环境中的解释器路径会写入启动配置；如果环境被移动，原路径可能失效，因此应在新路径下重新注册，并确认列表中对应的 kernelspec 位置。Python 官方文档也提醒，虚拟环境通常不适合直接搬迁，移动后应在新位置重建环境。(docs.python.org)

Notebook 能运行，却导入了错误的 Python 或依赖

内核启动成功，只能说明代码执行进程启动了；它不保证这个进程就是项目需要的解释器，也不保证科研依赖安装在其中。打开目标 Notebook，运行下面的检查单元：

import sys
print(sys.executable)
print(sys.prefix)
print(sys.base_prefix)

import numpy
print(numpy.__file__)

sys.executable 可显示当前代码实际使用的 Python 路径。若它指向系统 Python 或旧环境，而不是项目环境，说明 Notebook 选错了内核；若解释器路径正确，但关键包导入失败，则应检查包是否安装到了这个环境，而不是先去全局环境补装。Python 虚拟环境可通过 sys.prefix 和 sys.base_prefix 的差异辅助识别。(docs.python.org)

再检查 Notebook 的工作目录和项目依赖文件。相对路径读取数据失败，可能是启动目录不对，不一定是内核损坏；导入包版本不符，也不要通过覆盖全局 Python 或重装 JupyterLab来处理。先记下目标环境路径，再在该环境中安装项目所需依赖。

运行结果	更可能的问题	建议处理
`sys.executable` 不在项目环境路径内	Notebook 选错内核	切换到目标内核，再重新运行检查单元
解释器路径正确，导入关键包失败	包未安装到当前环境，或依赖版本不匹配	用该解释器对应的 `python -m pip` 检查和安装
包可导入，但读取项目文件失败	Notebook 工作目录或文件路径不匹配	核对当前目录与项目文件的相对路径
路径指向旧环境，或内核启动时报路径错误	环境被移动、删除或重建	在新环境重新注册，并移除或更正失效的内核项

注册后仍启动失败，按 kernelspec 和启动路径排查

kernelspec 不只是列表标签。Jupyter Client 文档说明，内核规格中的 kernel.json 包含启动命令 argv 和显示名称等信息；如果启动命令指向不存在的 Python，内核可能无法启动。(jupyter-client.readthedocs.io)

可以按这个顺序缩小范围：

重新运行 jupyter kernelspec list，确认项目内核的实际目录。
打开该目录中的 kernel.json，检查 argv 所指向的 Python 路径是否存在。
在启动 JupyterLab 的同一台主机上检查该路径；不要拿本地 Mac 的路径去对应远程服务。
若环境被移动或删除，先在新环境重新注册，不要只改界面显示名称。
新建一个空白 Notebook，选择该内核，只运行 import sys; print(sys.executable)。
如果最小测试可以运行，再回到项目 Notebook 检查依赖和工作目录；若仍不能启动，保留报错信息、启动命令和 kernelspec 路径，便于进一步定位。

这些现象适用于多种 Jupyter 环境，不应直接归因于 JupyterLab 4.6 的普遍缺陷。JupyterLab 的运行面板可以查看当前运行的内核；关闭 Notebook 后，服务端内核也可能继续运行，因此判断“内核没了”时，区分列表中的可用规格与已经运行的会话。(jupyterlab.readthedocs.io)

用验收清单确认修复适合科研任务

✅ 在 Notebook 中选中刚注册的项目内核。
✅ 运行 import sys; print(sys.executable)，保存实际解释器路径。
✅ 导入项目的关键依赖，并查看其文件位置或版本。
✅ 用不含敏感数据的小样本运行项目关键分析步骤。
✅ 记录 Python 路径、内核显示名、依赖清单和工作目录，方便日后复现。

决策条件	处理选择	适用边界
只是本机服务看不到已安装的项目环境	在目标环境注册 `ipykernel`	无需先重装 JupyterLab
内核可运行，但项目导入或路径错误	修正内核选择、依赖位置或工作目录	先确认解释器，再处理项目依赖
项目需要验证 macOS 行为，实验室没有可用 Mac	评估远程 Mac 作为补充验证环境	先核实访问方式、交付方式和数据要求
长期高负载运行，或必须连接本地物理设备	比较自有设备或实验室设备方案	远程环境不一定适合这类工作

如果还需要整理 Mac 上的 Python 项目环境，可继续阅读本站的科研环境与使用指南；若正在比较本地 Mac 与远程环境的取舍，也可参考Mac 方案对比。

只因为内核没有注册，不值得立刻购买或租用 Mac；按目标环境补装 ipykernel，往往就能解决。若研究任务确实要求在 macOS 上验证，而实验室只有 Linux 或 Windows 环境，本地环境可能无法复现 macOS 特有的行为，自购设备又需要先承担采购和维护；共享设备还受使用安排影响。此时，HireVM 的远程 Mac 可作为补充验证选项，但它不能替代内核注册排障，也不保证具体科研项目兼容。先核对远程 Mac 的访问方式与适用边界，再根据数据要求、使用周期和是否需要本地物理接口决定是否租赁。