内核崩溃多因显存oom或心跳超时，非代码错误；pytorch需手动zero_grad()和用.item()防泄漏；应调大kernel_info_timeout与ping_interval、禁用autorestart、强制matplotlib使用agg后端。
内核崩溃不是代码写错了，而是资源耗尽或通信中断的信号——尤其在跑 PyTorch/TensorFlow 模型时，Kernel died, restarting 大概率是显存 OOM 或心跳超时，不是死循环。
PyTorch GPU 显存泄漏必须手动切断计算图
训练循环里没调用 optimizer.zero_grad() 或没用 .item() 提取标量值，会导致显存持续累积。Jupyter 不会自动释放带 requires_grad=True 的张量引用，哪怕你只存了个 loss 到列表里。
- 错误写法：
losses.append(loss)—— 整个前向+反向图被钉在显存中 - 正确写法：
losses.append(loss.item())或losses.append(float(loss)) - 每次迭代开头加
optimizer.zero_grad()，避免梯度叠加 - 怀疑泄漏时，在终端运行
nvidia-smi观察显存是否单边上涨
kernel_info_timeout 和 ping_interval 必须调大
Jupyter 前端默认每 3 秒发一次心跳，连续几次收不到响应就判定“死亡”。模型加载、数据预处理或大 tensor 创建常卡在这几秒里，触发误杀。
- 改配置前先执行：
mkdir -p ~/.jupyter && jupyter notebook --generate-config - 追加两行：
echo "c.NotebookApp.kernel_info_timeout = 120" >> ~/.jupyter/jupyter_notebook_config.py - 再追加：
echo "c.NotebookApp.ping_interval = 10" >> ~/.jupyter/jupyter_notebook_config.py -
ping_interval别超过 30，否则前端可能直接断连
禁用 autorestart 才能区分真崩溃和假卡顿
默认自动重启会清空所有变量，掩盖真实问题。关掉它，你才能看到内核是静默卡住，还是直接抛出 Killed 或 Segmentation fault。
- 启动时加参数：
jupyter notebook --NotebookApp.autorestart=False - 或在配置文件加：
c.NotebookApp.autorestart = False - 此时内核挂掉后页面停在
Kernel died, restarting不动，立刻去看终端日志 - 有 traceback 或
Killed字样 → 真崩溃；只有长时间静默 → 计算阻塞，不是代码 bug
Matplotlib 后端冲突会静默杀死内核
某些系统（尤其是 macOS 或远程服务器）上，matplotlib 默认 GUI 后端（如 MacOSX 或 TkAgg）与 Jupyter 的事件循环打架，不报错，直接 kill 进程。
- 在 notebook 最开头加三行：
import matplotlib
matplotlib.use('Agg') # 强制非交互模式
import matplotlib.pyplot as plt
- 别用
%matplotlib inline后再切后端，顺序错了也白搭 - 如果要用绘图交互，换
widget后端：pip install ipympl+%matplotlib widget
真正难排查的从来不是报错，而是没报错——比如显存缓慢泄漏、Matplotlib 后端静默退出、心跳超时误判。这些都不会在 notebook 里留痕迹，必须盯终端日志、看 nvidia-smi、关 autorestart 才能抓到。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
