内核无响应时最直接的强制中断方式是按Ctrl+M后按I发送SIGINT信号，等价于Ctrl+C；若无效则依次执行Kernel→Interrupt Kernel或Kernel→Restart Kernel and Clear All Outputs，极端情况可kill -9终止对应ipykernel进程。
内核无响应时怎么强制中断执行
死循环最直接的表现是 Kernel busy 状态持续、输入单元格左侧出现 * 号、UI 卡死无法操作。这时候不能等它自己结束，必须手动干预。
优先尝试快捷键：Ctrl + M（Mac 是 Cmd + M）后按 I，即组合操作 Ctrl+M, I —— 这会向当前内核发送中断信号（SIGINT），等价于在终端里按 Ctrl+C。大多数 Python 死循环（比如 while True: 未设 break）能被立即打断。
如果没反应，说明内核已完全卡死或陷入 C 扩展层（如 NumPy 底层循环、某些 Cython 模块），这时需要重置内核：
- 菜单栏点 Kernel → Interrupt Kernel（先试一次）
- 再不行就选 Kernel → Restart Kernel and Clear All Outputs
- 极端情况可手动在终端查进程：
ps aux | grep jupyter，找到对应python -m ipykernel进程，用kill -9 [PID]强杀
写循环前怎么加安全防护
不是所有死循环都源于疏忽，有些是调试时临时写的测试逻辑，但忘了加出口。提前加几行防御代码成本极低，却能避免反复重启内核。
推荐在任何可能长耗时的循环开头插入检查：
import time
start_time = time.time()
max_duration = 5 # 秒
<p>for i in range(1000000):
if time.time() - start_time > max_duration:
print(f"⚠️ 超时退出，已运行 {int(time.time() - start_time)} 秒")
break</p><h1>原有逻辑</h1><p>更稳妥的做法是配合 enumerate 限次数：
- 用
for i, x in enumerate(data, 1):+if i > 1000: break - 对
while循环，务必初始化计数器并更新：step = 0; while condition and step - 避免裸写
while True:，除非内部有明确且可靠的break或return
为什么 time.sleep() 有时也救不了死循环
看起来加了 time.sleep(0.1) 就该“让出控制权”，但实际中仍可能卡死——关键在于：Jupyter 内核是单线程事件循环，sleep 只是暂停当前线程，并不释放 GIL 或让出 notebook 的消息泵。
尤其当循环体里有阻塞式 IO（如未设 timeout 的 requests.get()）、或调用了底层无响应的 C 函数时，sleep 完全无效。
- 真正有效的暂停是
await asyncio.sleep(0.1)（需在 async cell 中运行） - 普通场景下，
sleep仅对纯 CPU 循环起作用，且必须配合超时/计数双重判断 - 网络请求务必加
timeout=3，文件读取用open(..., timeout=2)（Python 3.11+）或包装成带超时的threading.Timer
重启内核后变量和状态全丢了怎么办
这是最让人烦躁的连带后果：中断或重启后，所有 import、全局变量、模型加载、数据预处理结果全部清空。频繁重启等于重复劳动。
缓解办法不是避免中断，而是减少依赖运行时状态：
- 把数据加载、模型初始化、配置读取封装进函数，比如
load_data()、init_model()，需要时重新调用 - 用
%store魔法命令暂存小变量：%store df→ 下次重启后%store -r df恢复 - 对大对象（如训练好的模型），保存到磁盘：
torch.save(model, "model.pt")，重启后torch.load() - 禁用自动重启：在 Jupyter 设置里关掉
Auto-restart kernel on error（如果开着）
真正的复杂点不在怎么停循环，而在于：你永远不知道哪一行 C 扩展、哪个第三方库的底层调用会绕过 Python 的中断机制。所以防护要前置，恢复要可重复，别指望一次写对。
