凌晨两点，你盯着屏幕，调试一个 Java 方法。
int foo() {
return random.nextInt();
}
你在 return 那行打了个断点，信心满满地按下调试按钮。程序停了，光标停在 return 上，你满怀期待地看向 Variables 面板——空的。 没有返回值，没有临时变量，什么都没有。你只知道这个方法即将返回，但返回的是 42 还是 -1，IDE 守口如瓶。
这就像你去餐厅点菜，服务员告诉你“菜马上就好”，但不告诉你端上来的是牛排还是泡面。
于是你只能：手动加个临时变量、重新编译、再跑一遍；或者祭出祖传的 System.out.println，把返回值打印出来，然后手动删掉。一个断点能解决的事，你花了五分钟。
在最新的IDEA2026.3 EAP中，终于开始解决这个问题了
痛点的场景描述得清清楚楚：在方法退出断点（emulated 或非 emulated）停下时，实际结果是没有任何方式获取返回值。期望结果是——让返回值出现在 Variables 视图里。
七个月。一个“让我看看返回值”的需求，走完了从提出到修复的全流程。 这速度放在开源社区算正常，放在“每天都要调试”的开发者眼里，属于“我都快忘了还有这回事”。
调试的本质就是验证假设。你怀疑某个方法算错了，你想看它到底返回了什么。现在 IDEA 的做法是：断点停在 return 行，但你看不到返回值——你只能看到方法入口传进来的参数，以及方法内部还没销毁的局部变量。
对于简单方法，你可以自己脑补返回值。对于复杂方法，你只能猜。对于链式调用，你直接放弃。
Variables 视图里没有返回值，就像侦探小说里没有凶手。 你跟着线索走了一路，最后告诉你“真相就在那里”，但不告诉你是什么。
你打断点，程序停，返回值就在那儿。简单、直接、不废话。
这才是调试器该有的样子。你不需要为了看一个返回值，把整个方法改得面目全非。你只需要停下来，看一眼，然后继续。
一点小感慨
这个 issue 最扎心的地方在于：它描述的是一个如此基础的需求，却等了七年。 Java 调试器从诞生那天起就能看局部变量、能看调用栈、能条件断点，但“方法返回了什么”这个最朴素的问题，一直没人解决。
不是技术做不到。是没人提，或者提了没人排期。直到 Vladimir 在七个月前敲下那段 int foo() 的示例代码，事情才开始动。
所以，如果你也有一个“这功能怎么还没有”的怨念，别憋着。去提 issue。 哪怕等七个月，至少七个月后有人会把它修好。而你如果不说，它可能再等七年。
