一个令人抓狂的场景

想象一下，你正在 IDE 中专注地调试代码，想把终端窗口从底部拖到编辑器侧边栏，以便更高效地利用屏幕空间。拖拽、释放，然后——终端崩了。进程重启，历史记录丢失，你的工作流被硬生生打断。

这不是某个小众编辑器的偶发问题。这正是jetbrains idea最近我遇到的一个bug ：终端在拖拽到编辑器区域后重启，让开发者不得不重新配置工作环境 。

问题是这样的
我开了3个终端的tab

接着我想把终端tab移动到编辑器区域，只需要右击中高端tab的名字，选择Move to editor

当我把这2个都移动到编辑区

把第二个易懂到第一个位置的时候，第二个终端里面之前执行过的记录就空空如也了。

为什么“拖拽终端”会触发崩溃？

从技术层面看，这个问题并非表面那么简单。现代 IDE 中的终端早已不是简单的命令行窗口，它是一个独立的进程或服务，承担着：

• 维护 shell 会话状态
• 管理环境变量和路径
• 与编辑器 UI 进行复杂的事件通信
• 支持分屏、标签页、拖拽重排等交互

当用户将终端从一个容器（底部面板）拖拽到另一个容器（编辑器区域）时，IDE 需要完成一系列底层操作：分离进程、重新挂载 UI、重新建立事件监听。任何一个环节出错，就可能导致终端进程被意外终止或重启 。

类似的 bug 在 VS Code 的终端编辑器功能中也出现过。VS Code 团队在实现 Move Terminal into Editor Group 功能时，就遇到过“窗口重载后终端随机打乱”、“终端命令在编辑器中无法正常工作”等问题 。

新特性 vs 稳定性：IDE 厂商的永恒博弈

这个 bug 还有一个有趣的点： 在 Cursor 等基于 VS Code 的编辑器中，同样的操作在新版终端实现下会触发崩溃，但启用“Legacy Terminal Tool”（旧版终端）后问题消失 。

这说明什么？

IDE 厂商正在不断升级终端底层架构，以支持更好的性能、更丰富的交互和更强大的扩展能力。但这种升级必然会带来兼容性和稳定性的风险。像 Cursor 这样的新兴编辑器，在快速迭代中更容易出现这类 edge case 。

JetBrains 的产品也不例外。有记录显示，类似问题可以追溯到 2011 年，JetBrains 官方也承认这是已知问题，但解决过程往往需要较长时间 。

从一个角度说，这种 bug 是 IDE 快速演进的副产品。十年前，我们甚至不会想到把终端拖拽到编辑器区域——那会儿终端还只是一个固定的底部窗口 。

现在，IDE 正在变得越来越像操作系统——窗口管理、进程调度、插件系统、终端模拟……这些功能不断向更复杂的层次演进。在这个过程中，bug 是不可避免的代价。

但我认为，IDE 厂商应该更加重视这类核心工作流的稳定性。终端拖拽重启虽然不像崩溃那样严重，但每次触发都会打断开发者的心流。这种“累积的摩擦感”往往比偶发的崩溃更让人沮丧。