日志断点实战演练
内容提要
IntelliJ IDEA 2026.2 改进了日志断点，可在不暂停程序、无需重新部署的情况下像 println 一样记录信息。文章以 gRPC 客户端-服务器为例，演示如何附加到远程进程，用日志断点逐步定位租户名未规范化的折扣计算 bug，在运行时测试修复，甚至通过副作用修改超时值，并可用 AI 代理技能自动完成。
延伸解读
日志断点与普通断点的关键差异
文章通过 gRPC 示例说明，普通断点会暂停服务器，而客户端设置的 deadline 会传播到服务器端，导致服务器在调试期间因超时而取消请求，使调试者进入无用的取消路径。日志断点不暂停程序，因此不会触发超时，能持续观察请求处理过程。这一差异在远程调试或超时敏感的场景中尤为关键。
日志断点相比 println 的实用优势
文章指出，日志断点无需修改代码、不会污染代码库，且可在不重新部署的情况下动态调整。它还能插入到依赖库内部进行日志记录，这是 println 难以做到的。在大型项目中，避免重新部署可以节省大量时间。但需注意，日志断点表达式仍在同一 VM 中执行，热路径上的复杂计算可能带来性能开销。
利用日志断点副作用修改运行时行为
文章演示了日志断点不仅能记录信息，还能通过副作用修改程序状态。例如，在 gRPC 库方法中重写 timeoutNanos 变量，将超时延长至五分钟，从而允许再次使用普通断点调试。通过多行表达式和请求头判断，可以仅对特定请求生效，避免影响共享环境中的其他请求。这展示了日志断点在调试中的灵活性和强大能力。
AI 代理技能辅助调试的适用场景
文章提到，IntelliJ IDEA 2026.2 捆绑了 ij-debugger AI 代理技能，可自动完成查找库方法、生成日志断点表达式等任务。当开发者不熟悉 gRPC 内部机制或没有时间探索时，AI 代理能快速提供针对性的运行时修改方案。这降低了调试复杂库的门槛，但文章也暗示其效果依赖于代理对代码的理解能力。
Q&A
IntelliJ IDEA 2026.2 的日志断点有什么新特性？
IntelliJ IDEA 2026.2 改进了日志断点，使其可以在不暂停程序、无需重新部署的情况下像 println 一样记录信息。新增了更快的设置方式：点击任意两个可执行行之间的装订线并输入要记录的表达式即可。此外，2026.2 版本通过插桩移除了调试器引入的开销，但重计算表达式仍可能耗时。
日志断点和 println 语句有什么区别？
日志断点与 println 类似，都不会暂停程序，但日志断点无需重新构建或重新部署即可修改。它们不会弄乱代码，可以灵活控制记录内容和时机（例如采样频繁事件），还能在依赖库中插入日志。最重要的是，它们可以节省昂贵的重新部署成本。
为什么在调试 gRPC 服务时日志断点比普通断点更合适？
因为 gRPC 客户端设置的截止时间会传播到服务器，服务器可能取消请求。使用普通断点会暂停服务器，导致调试时容易进入取消路径，且必须在超时窗口内完成调试。而日志断点不会暂停服务器，可以在控制台观察信息，避免触发超时。
如何用日志断点在运行时修改 gRPC 超时值？
可以找到设置超时的库方法（如 io.grpc.internal.ServerImpl.createContext），在 timeoutNanos 赋值后添加日志断点，通过副作用重写该变量。例如将其改为 5 分钟。还可以使用多行逻辑，仅对带有特定请求头的请求延长超时。
ij-debugger AI 代理技能能做什么？
ij-debugger AI 代理技能可以自动完成手动调试过程：找到读取截止时间的位置，并生成只修改目标请求的日志断点表达式。即使不了解 gRPC 内部机制，也能快速获得针对性的解决方案并继续调试。
在日志断点中如何只对特定请求延长超时？
可以在日志断点中使用多行逻辑，解析请求头，仅当请求包含特定头（如 Debug）时，将 timeoutNanos 改为 5 分钟，并返回确认信息。其他请求保持正常截止时间。
