2023年Q3，我們團隊一個DTO加字段的PR，平均 review 時間從4小時漲到11小時。不是業(yè)務變復雜了，是樣板代碼的債務終于到期。

Java 開發(fā)者都懂這種痛。紙上流程干凈得像瀑布：加字段、改映射、跑測試、合并。真進代碼庫，你會發(fā)現(xiàn)那個字段像觸手怪——構造函數(shù)、建造器、序列化器、校驗注解，最后還有一個誰都不想點開的工具類。

我們的 DTO 層就這樣，從"有點啰嗦"滑向"明顯超重"。

從 Lombok 到 Records，不是追新，是還債

先說清楚：換 Records 不是為了在簡歷上寫"掌握 Java 14+ 新特性"。是某天我盯著一行 @Builder.Default 看了五分鐘，突然想不起它當初為什么存在。

Lombok 是個好拐杖。2017 年我們引入它時，Getter/Setter 的噪音確實消失了。但拐杖用久了，你會忘記腿本來該怎么走。

我們的 DTO 逐漸長成這樣：Immutable 用 @Value，可變對象用 @Data，建造器模式套 @Builder，再加上 Jackson 的注解、Hibernate Validator 的注解、自定義的 @Mapper 注解。一個 8 字段的 DTO，文件行數(shù)輕松破 80。

更隱蔽的問題是"隱形耦合"。Lombok 生成的代碼不參與編譯期檢查，IDE 里跳轉(zhuǎn)不到，重構時全靠搜索。有次我們改了一個字段名，@Builder 生成的全參構造器沒跟著變，測試全綠，生產(chǎn)環(huán)境序列化報錯——因為 Jackson 用的還是舊的字段名映射。

Records 的吸引力在這里：它是語言級特性，不是字節(jié)碼魔術。編譯器看得見，IDE 跟得上，反射也認。

遷移不是搬家，是斷舍離

我們沒搞大爆炸重構。選了一條最臟的業(yè)務線試點——訂單域的 37 個 DTO，覆蓋創(chuàng)建、查詢、導出三種場景。

第一個發(fā)現(xiàn)：Records 的緊湊是真實的。public record OrderDTO(String id, BigDecimal amount, Instant createdAt) {} 這一行，等效于 Lombok 時代的 15 行：類聲明、@Value、4 個字段、4 個 Getter、全參構造器、equals/hashCode/toString。

但省行數(shù)不是重點。重點是這些行為現(xiàn)在由 JVM 保證，而不是一個注解處理器在編譯期偷偷改寫 AST。

第二個發(fā)現(xiàn)：建造器模式必須放棄。Records 的字段是 final 的，且必須在構造時初始化。我們原來的 @Builder 鏈式調(diào)用寫得很爽，OrderDTO.builder().id("123").amount(new BigDecimal("99.00")).build()，現(xiàn)在得改成 new OrderDTO("123", new BigDecimal("99.00"), Instant.now())。

團隊里有人抵觸："參數(shù)一多，構造器調(diào)用可讀性太差。"我們試了兩種妥協(xié)：小 DTO 直接裸構造，大 DTO 手寫靜態(tài)工廠方法，按業(yè)務語義命名參數(shù)。比如 OrderDTO.forNewCart("123", "99.00") 比裸 new 好懂，又不依賴字節(jié)碼生成。

第三個發(fā)現(xiàn)：Jackson 的兼容性比預期順滑。ObjectMapper 注冊 JavaTimeModule 后，Records 的序列化/反序列化開箱即用。唯一要改的是字段命名策略——我們原來用 @JsonProperty 覆蓋駝峰，現(xiàn)在統(tǒng)一在 ObjectMapper 配置層解決，DTO 本身保持干凈。

那些沒寫在 Release Note 里的成本

遷移完 37 個 DTO，我們算了筆賬。

正面：DTO 文件平均行數(shù)從 67 降到 12。代碼審查時， reviewer 能一眼看完數(shù)據(jù)結構和校驗規(guī)則，不用再展開 Lombok 生成的折疊代碼。

負面：MapStruct 的映射代碼要重寫。原來 Lombok 的 @Builder 支持 targetBuilder 模式，Records 沒有建造器，只能改用 @Mapping 注解直接指定構造參數(shù)。17 個映射接口，每個多花了 20 分鐘調(diào)整。

還有一個長期成本：團隊培訓。 junior 開發(fā)問得最多的是"Records 能繼承嗎"（不能）、"能加 Setter 嗎"（不能）、"那業(yè)務需求要改字段怎么辦"（新建實例）。這些問題 Lombok 時代不存在，因為 @Data 什么都能干，也什么都敢干。

我們的選擇是：把 Records 的約束當成設計審查。如果某個 DTO 真的需要可變字段，說明它可能不是純數(shù)據(jù)載體，該拆成狀態(tài)機或者移到領域?qū)印?/p>

試點三個月后，訂單域的生產(chǎn) bug 率沒明顯變化，但 DTO 相關的代碼審查評論數(shù)從平均每 PR 8.3 條降到 2.1 條。大部分爭議從"這個字段該不該加 @NonNull"變成了"這個字段該不該存在"。

現(xiàn)在回頭看 Lombok

我們沒卸載 Lombok。日志用的 @Slf4j、異常類的 @StandardException 還在服役。只是 DTO 這個場景，Records 的"少即是多"更貼合我們現(xiàn)在的需求。

有個細節(jié)挺有意思：JDK 21 的 Record Patterns 和 Switch 模式匹配，讓我們的 DTO 消費代碼又短了一截。原來 if (dto instanceof OrderDTO) 配強制轉(zhuǎn)型，現(xiàn)在直接 case OrderDTO(String id, var amount, _) -> ...，解構和判斷一步完成。

這是語言特性疊代的復利。2017 年我們選 Lombok，是因為 Java 8 的語法表達能力不夠。2024 年語言本身追上來了，拐杖就該放回儲藏室。

你們團隊的 DTO 現(xiàn)在是什么狀態(tài)？是 Records 全量替換，還是 Lombok 繼續(xù)扛主力，或者兩者混用、邊界模糊？