## 1. 理解 kernel 与 Python 版本的绑定关系 Jupyter notebook 本身只是一个界面外壳，真正执行代码的是背后独立运行的 kernel。这个 kernel 不是 notebook 自带的，而是你系统里某个 Python 解释器“被注册”进去的。换句话说，notebook 启动时，它会去读取一个配置文件（`kernel.json`），里面明确写着：“请用 `/Users/xxx/miniconda3/envs/py37/bin/python` 这个可执行文件来启动内核”。哪怕你当前终端里 `python --version` 显示的是 3.11，只要 kernel 指向的是 py37 环境里的 3.7.12，那 notebook 里跑的就是 3.7。我第一次遇到这个问题时，在 notebook 里敲 `!which python` 和 `import sys; sys.executable`，发现两个路径完全不一样——前者是 shell 当前环境的 python，后者才是 kernel 真正调用的解释器。这种分离设计本意是好的：支持多语言、多版本共存；但副作用也很明显：一旦那个被注册的 Python 环境被删了、升级崩了、或者 pip install 把依赖搞乱了，kernel 就会直接报错“Kernel died, restarting”，或者更隐蔽地卡在 “Connecting to kernel…” 状态。这时候你刷新页面、重启 notebook、甚至重装 jupyter 都没用，因为问题根本不在 notebook，而在那个被硬编码进 `kernel.json` 的路径。我试过最典型的场景是：用 conda 更新了 base 环境的 Python 到 3.10，结果原来注册的 `python3` kernel 指向的还是旧版 3.8 的二进制文件，而那个文件已经被 conda 在更新过程中悄悄移除了。此时 `jupyter kernelspec list` 还能看见它，但点开对应目录一看，`kernel.json` 里写的路径已经是个 404。所以解决这类问题的第一步，永远不是急着重装，而是先确认：这个 kernel 到底想用哪个 Python？它现在还能不能找到那个 Python？ ## 2. 定位当前 kernel 的真实 Python 路径与版本 别信界面上显示的 kernel 名字，比如“Python 3”，那只是个 display-name，毫无技术含义。真正管用的是它底层指向的可执行文件。操作分三步走，每一步我都实测过，确保在 macOS、Linux 和 Windows（WSL）下都稳。 第一步，打开终端，运行： ```bash jupyter kernelspec list ``` 你会看到类似这样的输出： ``` Available kernels: python3 /Users/alex/Library/Jupyter/kernels/python3 myproject /Users/alex/Library/Jupyter/kernels/myproject julia-1.9 /Users/alex/Library/Jupyter/kernels/julia-1.9 ``` 注意看第二列，那是 kernel 配置文件所在的完整路径。我们只关心 `python3` 这一行（或者你正在用的那个名字）。接下来，进入这个路径： ```bash cd /Users/alex/Library/Jupyter/kernels/python3 ls -la ``` 你应该能看到 `kernel.json` 这个文件。用任何文本编辑器打开它，重点看 `"argv"` 这个字段。典型内容如下： ```json { "argv": ["/Users/alex/miniconda3/envs/py37/bin/python", "-m", "ipykernel_launcher", "-f", "{connection_file}"], "display_name": "Python 3", "language": "python" } ``` 看到没？`argv` 数组的第一个元素，就是 kernel 启动时调用的 Python 解释器绝对路径。把它复制出来，然后直接在终端里执行： ```bash /Users/alex/miniconda3/envs/py37/bin/python --version ``` 如果返回 `Python 3.7.12`，说明它确实还在用老版本；如果返回 `-bash: /Users/alex/miniconda3/envs/py37/bin/python: No such file or directory`，那就坐实了——这个 kernel 已经指向一个不存在的路径，必须重建。还有一种情况是路径存在，但版本太低，比如 `3.6.15`，而你现在要跑的库（比如 PyTorch 2.0+ 或 scikit-learn 1.3+）明确要求 Python ≥3.8，那这个 kernel 本质上就“不再受支持”，即使它还能启动，也会在 import 时报 `ModuleNotFoundError` 或 `SyntaxError`。> 提示：不要跳过这一步直接重装。我踩过最大的坑就是没查路径，以为重装 ipykernel 就行，结果新装的 kernel 还是注册到了同一个坏路径上，白忙活半小时。 ## 3. 创建干净隔离的 Python 虚拟环境 确认问题根源后，下一步是建一个全新的、可控的 Python 环境。这里强烈建议放弃 `pip install virtualenv` 这套传统方案，直接上 conda 或 micromamba。为什么？因为 conda 不仅管理 Python 版本，还管理所有底层 C 库（如 numpy 的 OpenBLAS、pytorch 的 CUDA runtime），这些是纯 pip 搞不定的。我对比过：用 `python -m venv myenv && source myenv/bin/activate && pip install numpy`，在 M1 Mac 上经常编译失败或运行极慢；而 `conda create -n myenv python=3.9 numpy` 一行搞定，且性能稳定。具体命令如下： ```bash # 方案一：用 conda（如果你已安装 Anaconda/Miniconda） conda create -n jup39 python=3.9 -c conda-forge conda activate jup39 # 方案二：用 micromamba（比 conda 快 10 倍，推荐！） curl -Ls https://micro.mamba.pm/api/micromamba/osx-64/latest | tar -xvj bin/micromamba ./bin/micromamba create -n jup39 python=3.9 -c conda-forge ./bin/micromamba activate jup39 ``` 创建完后，立刻验证： ```bash which python python --version ``` 确保输出是你刚指定的版本（如 `3.9.18`），且路径指向 `envs/jup39` 目录。接着，必须在这个激活的环境下安装 `ipykernel`： ```bash pip install ipykernel ``` 注意：`pip` 前面不要加 `sudo`，也不要加 `--user`，因为我们要让这个 kernel 只属于当前环境。此时，`ipykernel` 会把当前环境的 Python 解释器路径写死进配置里，这才是安全的做法。我见过太多人用全局 pip 安装 ipykernel，结果注册出来的 kernel 指向的是系统 Python，而不是虚拟环境里的，导致后续所有操作都白费。> 注意：如果你用的是 Python 3.12，目前（截至 2024 年中）部分科学计算库（如 statsmodels、patsy）尚未完全适配，建议稳妥起见选 3.9 或 3.10。我在一个金融回测项目里试过 3.12，`import pandas as pd` 没问题，但 `import statsmodels.api as sm` 直接报 `ImportError: cannot import name 'ABC' from 'collections'`，退回到 3.10 后一切正常。 ## 4. 注册新 kernel 并完成切换 环境建好了，`ipykernel` 也装了，现在要把这个干净的环境“告诉” Jupyter。关键命令只有一个： ```bash python -m ipykernel install --user --name jup39 --display-name "Python (3.9)" ``` 拆解一下参数含义： - `python -m ipykernel install`：调用当前激活环境里的 ipykernel 模块来执行安装； - `--user`：把 kernel 配置安装到用户级目录（`~/.local/share/jupyter/kernels/`），不污染系统级位置； - `--name jup39`：这是 kernel 的唯一 ID，后续删除或管理都靠它，务必记牢； - `--display-name "Python (3.9)"`：这是 notebook 界面里显示的名字，支持中文和括号，建议带上版本号，避免混淆。 执行完后，再运行 `jupyter kernelspec list`，你会看到新增了一行： ``` jup39 /Users/alex/Library/Jupyter/kernels/jup39 ``` 此时，打开你的 notebook，点击右上角的 Kernel > Change kernel，下拉菜单里就会出现 “Python (3.9)”。选中它，Jupyter 会自动重启 kernel。为了彻底确认，新建一个 cell，输入： ```python import sys print("Python path:", sys.executable) print("Python version:", sys.version) print("IPython version:", __import__('IPython').__version__) ``` 运行后，输出应该全部指向 `jup39` 环境，例如： ``` Python path: /Users/alex/miniconda3/envs/jup39/bin/python Python version: 3.9.18 (main, Sep 11 2023, 13:41:44) IPython version: 8.12.2 ``` 如果 `sys.executable` 还是旧路径，说明你没在正确的环境下执行 `install` 命令，或者 notebook 没重启。这时候别硬扛，直接关掉所有 notebook 标签页，终端里 `jupyter notebook --no-browser` 重新启动一次。我习惯在注册新 kernel 后，顺手把旧的、有问题的 kernel 删掉，避免误选： ```bash jupyter kernelspec remove python3 # 或者更精准地删掉你确认已损坏的那个 jupyter kernelspec remove old_broken_kernel ``` 删之前它会问你 `Remove kernel 'old_broken_kernel'? [y/N]`，输 `y` 回车即可。整个过程不需要动 `~/.jupyter` 目录下的任何配置文件，也不需要重装 jupyter 或 notebook 包，纯粹是“换一个干净的发动机”，既快又稳。 ## 5. 多版本 kernel 的日常管理实践 当你的项目越来越多，每个项目依赖的 Python 版本和包都不一样时，光会建一个新 kernel 是不够的，得有一套可持续的管理方法。我的做法是：**每个项目根目录下放一个 `environment.yml` 文件，并用统一命名规则注册 kernel**。比如，一个 NLP 项目需要 PyTorch + Transformers，我就在项目文件夹里建 `environment.yml`： ```yaml name: nlp-prod channels: - conda-forge dependencies: - python=3.9 - pytorch - transformers - jupyter - ipykernel ``` 然后在项目目录下运行： ```bash conda env create -f environment.yml conda activate nlp-prod python -m ipykernel install --user --name nlp-prod --display-name "NLP (PyTorch 2.0)" ``` 这样，kernel 名字 `nlp-prod` 和项目名一致，显示名 `NLP (PyTorch 2.0)` 带上了关键依赖信息，一眼就能分辨。我电脑里现在有十几个 kernel，全靠这套命名法不迷路。另外，我从不手动编辑 `kernel.json`，因为一旦手抖改错路径，kernel 就废了。所有注册动作都通过 `python -m ipykernel install` 完成，它会自动生成合法的 JSON。还有个小技巧：如果你想让某个 kernel 只对当前项目生效（比如团队协作时不想污染队友的全局 kernel 列表），可以去掉 `--user` 参数，改用 `--prefix ./mykernel`，这样 kernel 配置会放在当前目录下，启动 notebook 时加 `--kernelspec-path ./mykernel` 即可。不过日常使用，`--user` 是最省心的选择。最后提醒一句：定期清理。每隔两三个月，我会运行 `jupyter kernelspec list`，把那些 `test-env`、`tmp-2023`、`old-try` 这类临时 kernel 全部删掉。留着它们不仅占磁盘空间，更会在 kernel 切换菜单里造成视觉干扰，增加误操作概率。毕竟，一个清晰、精简的 kernel 列表，本身就是高效工作的开始。