KeyboardInterrupt不是bug而是用户主动中断信号，PyCharm停止按钮通过发送SIGINT触发该异常；应避免用红色方块终止，改用Ctrl+F2/Cmd+F2强制结束，或升级至2024.1+并启用pydev.debugger.skip.keyboard.interrupt选项。
KeyboardInterrupt 不是真正的报错，而是你按了 Ctrl+C（macOS 是 Cmd+C）主动中断程序时 Python 抛出的标准异常。PyCharm 里看到红色堆栈、进程退出码 130 或 1，基本就是这个原因——不是代码写错了，是你（或别人）手动停掉了它。
为什么 PyCharm 调试时点“停止”按钮会触发 KeyboardInterrupt？
PyCharm 的调试器在终止运行中的进程时，并不总是优雅地 kill 进程，而是向 Python 解释器发送 SIGINT 信号，这直接映射为 KeyboardInterrupt 异常。尤其在以下场景更常见：
- PyCharm 版本较老（如 2022.x 及更早），对 Python 3.9+ 的信号处理不够稳定
- 代码里有长时间阻塞操作（如
time.sleep(10)、input()、torch.utils.data.DataLoader等等待 I/O 的地方） - 使用 Conda 环境 + WSL 时，信号传递路径变长，容易被误判或延迟响应
- 在 PyTorch 训练循环中调用
loss.backward()前被中断，堆栈就卡在 autograd 引擎里，看起来像“崩溃”
怎么避免被 KeyboardInterrupt 中断打断正常流程？
如果你的程序本就该支持用户中断（比如 CLI 工具、训练脚本），那就主动捕获并清理资源；如果只是不想让调试器“假报错”，重点在运行方式和环境配置：
PyCharm 2026.2
下载
PyCharm 2026.2是 JetBrains PyCharm 的指定版本安装包，下载地址指向官方 Windows 安装包直链，可用于旧项目兼容、版本回退和环境测试。
- 调试时别依赖左上角的“红色方块”停止按钮，改用
Ctrl+F2（Windows/Linux）或Cmd+F2（macOS）强制终止，它更接近系统级 kill，不走 Python 异常路径 - 在主逻辑外层加一层
try...except KeyboardInterrupt，但注意：不要捕获Exception—— 它会吞掉KeyboardInterrupt，导致你再也无法 Ctrl+C 退出 - 若用 PyCharm 2024.2+，检查是否启用了 “Emulate terminal in output console”（运行配置 → Execution），关掉它有时能缓解信号误传
- Conda 环境下运行失败？试试在 PyCharm 的 Python interpreter 设置里，把 interpreter path 指向
conda环境里的python.exe（Windows）或python（macOS/Linux），而不是conda命令本身
PyCharm 注册表里那个 condaerror: KeyboardInterrupt 怎么回事？
这不是 bug，是 PyCharm 调试器与 conda 环境交互时，把 KeyboardInterrupt 错标成了 CondaError。它只影响日志显示，不影响实际行为。解决方法很窄：
- 打开
Help → Find Action → Registry - 搜索
pydev.debugger.skip.keyboard.interrupt - 勾选它（PyCharm 2023.3+ 支持），就能让调试器忽略
KeyboardInterrupt的异常高亮 - 没这个选项？说明版本太低，升级到 2024.1 或更高更省事
KeyboardInterrupt 本身，而是它暴露出来的底层问题：信号传递链路太长、异步/多进程上下文不清、或调试器与解释器版本不匹配。别急着加 try/except，先确认你是不是真想中断——或者，是不是根本没在调试，只是忘了关掉一个跑着的训练进程。 
