副标题：深入探索 Java 开发中的一个隐蔽陷阱
在 Java 开发的世界里，Lombok 是一个让人又爱又恨的工具。它以其简洁的注解，为我们省去了大量样板代码的编写，但同时，它也可能在不经意间让我们掉进坑里。今天，我们就来聊聊一个由 Lombok 引起的 NullPointerException 问题，以及它给我们带来的深刻启示。
问题的浮现
故事开始于一个稳定的服务接口，它已经无声无息地运行了很长时间，直到一个新的服务尝试对接它。突然间，空指针异常 （NullPointerException） 成为了讨论的焦点。
开发者们很快排除了最显而易见的原因：服务接口的入参对象 reqDto 不可能为 null 。那么，问题出在哪里呢？
深入探索
在一番推理和排查之后，开发者们将目光投向了 Lombok 的 @Builder 注解。一个使用 @Builder 注解构建的 ReqDto 对象，竟然在某个字段上出现了 null 。但这个字段明明有默认值，为什么会是 null 呢？
Lombok 的 @Builder.Default 注解
经过一番搜索和实验，开发者们发现了 @Builder.Default 注解。这个注解的作用是告诉 Lombok：这个字段有默认值，请在构建对象时使用它。没有它，即使是有默认值的字段，在通过 @Builder 注解构建对象时也会被设置为 null 。
官方的回应
在 GitHub 上，有一个相关的问题讨论。一些开发者认为这是 Lombok 的一个 bug，但官方将其视为一个 feature 。这个决定引发了一些争议，因为它违反了许多开发者的直觉和预期。
最小惊喜原则
在软件设计中，有一个原则叫做 「最小惊喜原则」（least-surprise principle） 。它要求程序的行为应该是一致的、可预测的，遵循领域内的惯例。 Lombok 的这一行为显然违背了这个原则，给开发者带来了 「惊喜」 。
教训与启示
这次经历给我们的教训是深刻的。首先，即使是看似简单无害的工具，也可能隐藏着复杂的坑。其次，作为开发者，我们需要对所使用的工具有深入的理解，不能盲目信任。最后，官方的文档和社区的讨论是解决问题的宝贵资源。
结语
Lombok 的这个坑，虽然给我们带来了困扰，但也让我们学到了宝贵的知识。在技术的世界里，不断学习和探索，是我们前进的动力。