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的侵入性降到了最低，因为它直接在编译器的内部流程中完成了所有工作。这与那些通过文本替换或生成新源文件的方式相比，无疑是更高级、更底层的玩法。
在原版的基础上做了一下修正评论没有提交正文的问题特价商品的调用连接问题去掉了一个后门补了SQL注入补了一个过滤漏洞浮动价不能删除的问题不能够搜索问题收藏时放入购物车时出错点放入购物车弹出2个窗口修正主题添加问题商家注册页导航连接问题销售排行不能显示更多问题热点商品不能显示更多问题增加了服务器探测 增加了空间使用查看 增加了在线文件编辑增加了后台管理里两处全选功能更新说明：后台的部分功能已经改过前台
编译期代码注入与运行时反射有何本质区别？
编译期代码注入（如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享受便利的同时，也要对其带来的隐性依赖有所认识。
