lombok通過Java注解處理器在編譯期修改ast實現代碼自動生成。1. 編譯時，javac掃描源碼并加載lombok注解處理器；2. 處理器獲取被注解標記的元素及其ast；3. 直接在ast中插入新節點如getter/setter；4. 修改后的ast交由編譯器生成含完整代碼的.class文件。與運行時反射相比，lombok無性能損耗、類型安全，但需ide插件支持且可能影響代碼可讀性及調試。
Java注解處理器在Lombok中的應用原理，核心在于Lombok巧妙地利用了java編譯器提供的標準注解處理API（Annotation Processing API），在代碼編譯階段，而非運行時，對源代碼的抽象語法樹（AST）進行修改和增強，從而自動生成那些我們日常編寫中重復性極高的樣板代碼，比如getter、setter、構造函數等。這就像是給編譯器裝了一個“外掛”，讓它在編譯前替你把代碼寫好，再進行編譯。
解決方案
Lombok的工作流程可以概括為以下幾步：
當Java編譯器（javac）開始編譯源代碼時，它會掃描所有的源文件，發現其中使用了Lombok的注解（如@Data, @Getter, @Setter等）。根據Java的注解處理規范（JSR 269），javac會查找并加載所有注冊的注解處理器。Lombok的核心就是一個實現了javax.annotation.processing.Processor接口的注解處理器。
立即學習“Java免費學習筆記（深入）”；
一旦Lombok的處理器被激活，它會獲得當前編譯輪次中所有被特定注解標記的元素信息。這些信息不僅僅是注解本身，更重要的是，處理器能夠訪問到這些代碼元素的抽象語法樹（AST）。AST是源代碼的樹形表示，編譯器在將源代碼轉換為字節碼之前，會先將其解析成AST。
Lombok的處理器會遍歷這個AST，識別出被Lombok注解修飾的類、字段等。然后，它不會生成新的.java文件，而是直接在內存中對AST進行“手術”——它會動態地向AST中添加新的節點，比如代表getter方法的MethodDeclaration節點，或者代表無參構造函數的ConstructorDeclaration節點。這些新添加的節點在結構上與你手動編寫的代碼所生成的AST節點是完全一致的。
當Lombok完成對AST的修改后，它會將修改后的AST交還給編譯器。對于編譯器而言，它看到的AST已經是包含了所有Lombok“生成”代碼的完整版本。編譯器會繼續后續的編譯流程，將這個修改后的AST轉換為字節碼（.class文件）。因此，最終生成的.class文件中包含了Lombok自動生成的代碼，而你的源代碼文件本身并沒有被改動。這就是為什么你在IDE里看不到那些方法，但編譯后的字節碼卻實實在在包含它們的原因。這種方式，我認為是相當優雅且高效的，它避免了運行時反射帶來的性能開銷，也保證了代碼的類型安全。
Lombok如何利用AST實現代碼生成？
說起Lombok如何利用AST來生成代碼，這其實是它最核心也最“魔法”的部分。AST，也就是抽象語法樹，它是編譯器在解析源代碼后，構建出來的一種數據結構，用樹的形式表示程序的語法結構。可以把它想象成源代碼的骨架，每一個節點都代表著代碼中的一個語法元素，比如一個類、一個方法、一個變量聲明，甚至是一個表達式。
Lombok的聰明之處在于，它并沒有去解析你的文本源代碼，而是直接在編譯器已經解析好的AST上動刀子。當Lombok的注解處理器被觸發時，它會拿到當前編譯單元的AST。比如，你有一個類User，里面有個字段name，你給User類加了@Data注解。Lombok的處理器會找到User類對應的AST節點，然后找到name字段對應的AST節點。接著，它會根據@Data注解的語義，在User類的AST節點下，動態地“插入”一個新的方法節點，比如一個getname()方法。這個新插入的方法節點，包含了方法的修飾符（public）、返回類型（String）、方法名（getname）、以及方法體內的語句（return this.name;）。
這個過程，就像是你在一個已經畫好骨架的圖紙上，直接添加新的結構。編譯器后續的工作，就是基于這個被Lombok修改過的“圖紙”來生成最終的二進制文件。這意味著，Lombok生成的方法，對于Java虛擬機來說，和我們手寫的方法沒有任何區別。它們都是實實在在存在于.class文件中的字節碼。這種直接操作AST的方式，避免了生成臨時源文件再編譯的復雜性，也讓Lombok的侵入性降到了最低，因為它直接在編譯器的內部流程中完成了所有工作。這與那些通過文本替換或生成新源文件的方式相比，無疑是更高級、更底層的玩法。
編譯期代碼注入與運行時反射有何本質區別？
編譯期代碼注入（如Lombok）和運行時反射，雖然都能實現一定程度上的“代碼動態性”，但它們在本質上是截然不同的，就好比一個是“預制件工廠”和一個是“現場改造隊”。
編譯期代碼注入，Lombok就是典型代表。它的核心在于“編譯期”，即在你的Java源代碼被javac編譯成.class文件的這個階段。Lombok的注解處理器在這個階段介入，直接修改了編譯器內部的抽象語法樹（AST）。這意味著，Lombok生成的代碼，在.class文件形成的那一刻，就已經實實在在地存在于其中了。這些代碼和我們手寫然后編譯的代碼沒有任何區別，它們是硬編碼在字節碼里的。
- 優點： 零運行時性能開銷，因為所有工作都在編譯時完成；類型安全，如果Lombok生成的代碼有語法錯誤或類型不匹配，編譯器會立即報錯；生成的代碼是真正的字節碼，可以直接被jvm執行。
- 缺點： 需要IDE插件支持才能正確識別生成的代碼；對開發環境有一定要求（需要Lombok作為編譯依賴）。
運行時反射，則完全是另一回事。它發生在“運行時”，即你的.class文件已經被JVM加載并執行之后。Java的反射API允許程序在運行時檢查類、方法、字段的信息，甚至在運行時動態調用方法、訪問或修改字段。它不是在編譯時修改字節碼，而是在程序運行起來后，通過JVM提供的機制去“看”和“操作”已經存在的類結構。
- 優點： 極大的靈活性，可以在運行時動態加載類、調用方法，實現插件化、AOP等復雜功能；無需修改源代碼或編譯過程。
- 缺點： 性能開銷較大，因為反射操作涉及動態查找和解析，比直接調用慢得多；類型不安全，許多錯誤只有在運行時才能發現；可能繞過訪問修飾符，增加代碼的復雜性和潛在風險。
所以，你看，Lombok是在“建房子”之前就把房間結構調整好了，而反射則是在“房子建好”之后，通過特殊工具去改變房間的布局。Lombok的目的是減少樣板代碼，提升開發效率，它追求的是編譯時的確定性和性能；反射則更多用于框架、工具或需要高度動態性的場景，它追求的是運行時的靈活性。兩者服務的目標和工作機制完全不同。
使用Lombok時可能遇到的挑戰或注意事項是什么？
盡管Lombok帶來了巨大的便利，但在實際項目中運用時，你確實可能會遇到一些小小的“別扭”或者說需要注意的地方，這就像任何一個強大的工具一樣，總有一些它自己的脾氣。
首先，最常見也最讓人頭疼的，可能就是IDE的支持問題。因為Lombok是在編譯期修改AST，你的IDE（比如IntelliJ idea、eclipse）在編輯代碼時，它自己的內部編譯器或語言服務并不會像javac那樣自動加載Lombok的處理器。這就導致你可能在IDE里看到一堆“找不到符號”、“方法不存在”的紅色波浪線，盡管你的代碼編譯運行是完全正常的。為了解決這個問題，你幾乎總是需要安裝Lombok的IDE插件。安裝后，IDE才能“理解”Lombok的魔術，正確地解析并顯示那些被Lombok生成的方法。如果忘記安裝或者插件版本不匹配，那開發體驗就有點糟糕了。
其次，是關于代碼的可讀性與調試。對于不熟悉Lombok的團隊成員來說，初次接觸時可能會覺得有些“魔法”。他們可能會疑惑，為什么一個類里沒有getter/setter方法，但代碼卻能調用它們？這在一定程度上增加了新成員的學習曲線。更進一步，當出現運行時異常，比如空指針異常，堆棧跟蹤（stack trace）可能會指向L一個被Lombok生成的方法，而這個方法在你的源代碼里是看不到的。這給調試帶來了一點點不便，你可能需要借助delombok工具來查看Lombok到底生成了哪些代碼，或者依賴IDE的良好支持來“透視”這些隱式代碼。
再來，是與序列化框架的兼容性。一些序列化框架（如Jackson、Gson）在進行json序列化/反序列化時，可能會依賴于默認的無參構造函數或者特定的getter/setter命名規范。Lombok的@NoArgsConstructor、@AllArgsConstructor等注解通常能很好地解決這些問題，但如果你同時使用了@Builder或者自定義了構造函數，就得特別注意這些框架的要求，確保Lombok生成的構造函數或方法符合它們的期望，避免出現序列化失敗的問題。
還有一點，雖然不常見，但值得一提的是與其他注解處理器的潛在沖突。如果你的項目同時使用了多個注解處理器，并且它們都嘗試修改或生成同一個類的AST節點，理論上存在沖突的可能性。不過，Lombok的設計通常比較健壯，這種沖突發生的概率很低，但如果真的遇到了奇怪的編譯錯誤，這可能是一個排查方向。
最后，一個更偏哲學層面的問題：對Lombok的過度依賴。Lombok確實能減少大量樣板代碼，但如果一個項目離開了Lombok就寸步難行，所有的getter/setter、構造函數都需要手動補齊，那在某些極端情況下（比如Lombok不再維護，或者需要移除它），遷移成本會非常高。所以，在使用Lombok享受便利的同時，也要對其帶來的隱性依賴有所認識。
