添加新Kernel的本质是让目标Python环境通过ipykernel注册为Jupyter可识别的通信端点；必须先激活该环境并安装ipykernel，再执行python -m ipykernel install --user --name=xxx --display-name="yyy"完成注册，最后验证kernel.json中argv[0]路径正确且重启Jupyter服务。
直接说结论：添加新 Kernel 的本质，不是“给 Jupyter 装个插件”，而是让某个 Python 环境（含解释器和包）通过 ipykernel 暴露为 Jupyter 可识别的通信端点。只要环境里有 Python 解释器、装了 ipykernel、并执行了注册命令，它就变成了一个可用内核——跟 Jupyter 启动时用的是哪个环境完全无关。
确认目标环境已激活且含 ipykernel
这是最容易卡住的第一步。很多人在 base 环境下运行 python -m ipykernel install，结果注册的却是 base 的内核，而不是你想要的 myenv。
- 必须先用
conda activate myenv或source activate myenv（macOS/Linux）切换到目标环境 - 再运行
python -m ipykernel --version，有输出才说明ipykernel已安装；没有就先conda install ipykernel或pip install ipykernel - 注意：不要在 base 环境里用
python3.9 -m ipykernel install这类“跨环境调用”，它可能指向错误的sys.executable
用 python -m ipykernel install 注册内核
这一步生成的配置文件决定了 Jupyter 启动时用哪个 Python 解释器执行代码。路径、名字、显示名全由该命令控制。
-
--user必须加，否则需要 root 权限，且容易污染系统级内核目录 -
--name是内核在文件系统里的唯一标识（如python311），后续删内核要用它：jupyter kernelspec remove python311 -
--display-name是 Notebook 界面里看到的名字（如Python 3.11 (myproj)），可含空格和括号，不影响功能 - 示例命令：
python -m ipykernel install --user --name=py311 --display-name="Python 3.11 (data-science)"
验证 kernel.json 是否指向正确解释器
注册后 Jupyter 并不校验路径是否真实存在，所以常见报错 “ModuleNotFoundError” 往往是因为 kernel.json 里 argv 数组第一项（Python 解释器路径）指向了旧环境或已删除的路径。
- 运行
jupyter kernelspec list，找到你的内核对应路径（如$HOME/.local/share/jupyter/kernels/py311） - 打开该目录下的
kernel.json，检查argv[0]是否等于目标环境的sys.executable（可在该环境下运行python -c "import sys; print(sys.executable)"获取） - 如果路径不对，手动编辑
kernel.json修改argv，不要依赖“自动发现” - Windows 用户特别注意：路径中反斜杠需转义为双反斜杠
\或改用正斜杠/
重启 Jupyter 并在界面中切换内核
Jupyter 启动时只读一次内核列表，改完配置不重启服务，Notebook 里就看不到新内核。
- 关闭所有 Jupyter 进程（包括后台的
jupyter-notebook或jupyter-lab），再重新启动 - 新建 Notebook 后，右上角 Kernel → Change kernel → 选择你刚注册的
--display-name - 切换后会重启内核，之前所有变量丢失——这是正常行为，不是错误
- 验证是否生效：在 cell 里运行
!which python（Linux/macOS）或!where python（Windows），输出应与kernel.json中的路径一致
真正麻烦的从来不是命令敲几行，而是注册时没激活对环境、kernel.json 里路径写错、或者改完没重启服务。这三个点踩中任意一个，都会导致“明明装了却找不到”或“找到了但 import 失败”。
