在 IntelliJ IDEA 2026.2 的众多新特性中，“Logpoints ” 可能不是最光鲜的，但它绝对是最能体现 IDE 深层智慧的功能之一。它解决的是一个每个开发者都经历过，却又常常习以为常的痛点：用println调试的狼狈。
告别println的“暴力美学”
官方描述非常直白：“Every developer has usedprintlnfor debugging at least once. But sometimes it is not the best approach.”（每个开发者至少用过一次println调试。但有时这并非最佳方法。）
这句话轻描淡写，却戳中了无数人的日常。当遇到棘手的 bug，我们的第一反应往往是：在可疑位置插入System.out.println("here")，或者打印某个变量的值。这种方法简单粗暴，但代价巨大：
- 污染代码库：调试完成后，你需要手动清理这些“临时”的打印语句。它们要么被遗忘在代码中，要么在代码审查时增加噪音。
- 缺乏上下文：
println只能打印你明确指定的内容。当你想知道“这个方法被谁调用了？”或“这个循环执行了几次？”时，你需要添加更多打印，并手动分析日志顺序。 - 无能为力：
println对第三方库的代码完全无效。当你怀疑问题出在某个依赖包里时，你束手无策。
Logpoints 正是这些问题的“优雅解”。它本质上是非暂停断点（non-suspending breakpoints）的升级版。你可以像设置断点一样，在代码行上设置一个 Logpoint，并指定当执行到此时要输出的信息。与断点不同的是，它不会暂停程序，只是静默地记录信息。
下面看看如何操作
选择replace call with logprint
这时候就会在控制台进行打印
添加logprint更快捷的方式是通过左边的gutter
左边会出现一个淡黄色圆形来表示logprint
超越打印：Logpoints 的优势
- 零代码侵入：Logpoints 是 IDE 的调试器功能，完全不会修改源文件。你不再需要在代码和调试输出之间来回切换，更不用担心“忘记删掉调试代码”的尴尬。这保持了代码库的整洁，也避免了因调试代码而引入新 bug 的风险。
- 更丰富的上下文：Logpoints 不是简单的字符串打印。你可以利用调试器的求值能力，输出任何复杂的表达式、对象状态、甚至是方法的返回值。你可以清晰地看到程序在那一刻的完整快照，而不仅仅是某个变量的值。
- 跨越代码边界：这是 Logpoints 真正的杀手锏。它可以直接在已编译的第三方库代码中设置。当调试一个开源框架或公司内部依赖包时，你可以直接“窥探”其内部行为，无需等待源码或重新编译。这彻底改变了排查深层问题的能力。
- 统一的输出溯源：新特性中提到，无论输出是来自 Logpoint、常规日志、还是
println，在调试器输出中，你都可以直接导航到产生该输出的代码位置。这是一个极其重要的体验提升。它把零散的文本输出，重新与代码逻辑连接了起来，让调试信息变得“可追溯”。
Logpoints 的引入，在我看来，标志着 JetBrains 对调试体验的一次深刻反思。它鼓励开发者从“被动地插入打印语句”转向“主动地探查运行中的程序状态”。
如果说println是“用蛮力撞开一扇门”，那么 Logpoints 就是“通过监控系统洞察屋内发生了什么”。后者显然更高级、更可控。我们可以预见一个未来：IDE 不仅能帮你写代码，还能在 AI 的辅助下，自动或半自动地设置 Logpoints 来定位问题根源。
当然，Logpoints 并非万能。对于简单的、一次性的调试，println的即时性仍有其价值。但当一个 bug 变得复杂、涉及多层调用或第三方代码时，Logpoints 提供的“干净、深入、可追溯”的调试体验，将成为你不可或缺的利器。它让调试从一种“必要的恶”，变为一种“有序的调查”。
