Jupyter kernel 因心跳丢失中断运行是因 VS Code 通过 ZeroMQ 每30秒检测内核响应，网络抖动、休眠或防火墙拦截导致 ping/pong 失败而误判失联；可通过修改 ~/.jupyter/jupyter_notebook_config.py 中 KernelManager.kernel_death_interval = 120 提升超时阈值至120秒解决。
为什么 Jupyter kernel 会因心跳丢失中断运行？
VS Code 的 Jupyter 扩展依赖 ZeroMQ 通道维持内核“心跳”（heartbeat），默认每 30 秒发一次 ping。一旦网络抖动、终端挂起、WSL 虚拟机休眠或防火墙拦截响应，VS Code 就判定内核失联，自动中断当前执行——哪怕代码还在跑，print() 输出卡住、time.sleep(60) 突然停在半途，就是典型表现。
这不是内核崩溃，而是通信链路被误判断开。尤其在远程 SSH 连接、WSL2、或使用公司代理/杀毒软件时，hb_ping 和 hb_pong 包容易被丢弃或延迟超限。
如何调高心跳超时阈值避免误判？
直接改内核配置比等 VS Code 修复更可靠。关键不是延长 VS Code 端的等待，而是让内核主动放宽响应窗口：
- 在目标 Python 环境中运行：
jupyter notebook --generate-config（生成~/.jupyter/jupyter_notebook_config.py） - 编辑该文件，添加两行（注意缩进）：
KernelManager.kernel_death_interval = 120<br>MappingKernelManager.kernel_death_interval = 120
- 重启 VS Code 或重新启动内核，生效后心跳超时从默认 30 秒变为 120 秒
⚠️ 不要改 ipykernel 的 --timeout 参数：VS Code 启动内核时不透传该参数，设了也无效。
立即学习“Python免费学习笔记（深入）”；
哪些场景下心跳必丢？必须绕过而非修复
有些环境根本无法稳定维持心跳连接，强行调参也没用，只能换通信模型：
-
SSH 远程服务器 + 断网重连：SSH 会话断开后，内核进程常被 SIGHUP 杀掉，心跳自然归零——必须用
nohup jupyter lab --no-browser --port=8888 --ip=0.0.0.0 &或tmux new-session -d -s jlab 'jupyter lab --no-browser'启动，再用 VS Code 的 Remote-SSH 连到对应端口 -
Windows + WSL2 + 防火墙/360/腾讯电脑管家：这些软件会静默拦截 ZeroMQ 的 UDP 心跳包——临时关闭防火墙或添加
python.exe白名单；若不行，降级ipykernel到6.26.0（6.27+ 默认启用新 socket 模式，更易被拦截） -
VS Code 内置终端被意外关闭：比如 Ctrl+Shift+P → “Terminal: Kill the Terminal”，会顺手 kill 掉所有子进程——永远不要在终端里直接
Ctrl+C中断jupyter，而要用 Kernel → Interrupt Execution
心跳恢复后变量/状态还存在吗？
不存在。心跳丢失触发的是「连接重连」，不是「续传」。VS Code 会新建一个通信通道，但内核进程本身可能还在跑（尤其远程场景），只是你失去了控制权。此时：
- 已运行的代码继续执行（如
for i in range(1000): time.sleep(1)），但你无法看到输出、无法中断、无法获取变量 - 重新连接后，内核实际是新会话，
pd、df全部未定义，必须重新运行导入和加载逻辑 - 想真正保留状态，得靠代码层设计：把中间结果写入
joblib.dump()或pickle文件，而不是依赖内核内存
真正的难点不在怎么连上，而在连上之后，你根本不知道刚才那 5 分钟里代码到底跑到哪一步了——日志没刷出、进度条卡住、变量不可查。这种“黑盒执行”才是心跳机制最隐蔽的代价。
