mybaits 3.5 自定义拦截器修改sql 报错nested exception is org.apache.ibatis.reflection.ReflectionException: There is no getter for property named 'delegate' in 'class com.sun.proxy.$Proxy223'

<think>好的，用户现在遇到了一个问题，使用MyBatis 3.5的自定义拦截器修改SQL时，报错提示“nested exception is org.apache.ibatis.reflection.ReflectionException: There is no getter for property named 'delegate' in 'class com.sun.proxy.$Proxy223’”。我需要帮他分析这个问题的原因，并提供解决方案。 首先，用户之前的问题是关于MyBatis-Plus版本3.4.3.4中的“delegate”属性缺失的问题，现在又遇到了类似错误，但这次是在使用MyBatis 3.5的自定义拦截器时出现的。这说明问题可能与代理对象和属性访问有关，但这次是在拦截器中修改SQL时触发的，可能需要不同的处理方式。 我需要考虑以下几个方面： 1. **代理对象的类型**：错误信息中提到的是`com.sun.proxy.$Proxy223`，这说明MyBatis可能使用了JDK动态代理来生成某个接口的代理对象。用户的自定义拦截器可能在处理某些参数时，这些参数是代理对象，而代理对象没有预期的“delegate”属性。 2. **拦截器的使用场景**：用户可能在拦截器中修改了SQL，例如通过拦截`StatementHandler`或`Executor`的方法，试图访问或修改参数对象。这时候，如果参数是代理对象，而拦截器中尝试通过属性名（如“delegate”）访问该对象的属性，但代理对象并没有对应的getter方法，就会抛出反射异常。 3. **参数传递问题**：用户可能在Mapper接口的方法中传递了被Spring AOP代理的对象（比如Service层的代理对象），而MyBatis在处理这些参数时，无法正确解析其中的属性，导致反射异常。 接下来，我需要分析可能的原因，并给出对应的解决方案： - **原因一：拦截器处理了代理对象，并尝试访问其不存在的属性**：当拦截器在处理参数时，如果参数是Spring的JDK动态代理对象（比如被@Transactional注解的Service类），这些代理对象可能没有用户期望的属性，如“delegate”。拦截器可能在SQL处理过程中引用了该属性，导致异常。 - **原因二：Mapper方法参数传递了代理对象**：用户可能在调用Mapper方法时，错误地传递了一个被AOP代理的对象（比如Service实例），而不是实际的实体对象。例如，传递了`this`引用，而该引用指向的是代理对象，而非原始对象。 - **原因三：自定义拦截器中的属性引用错误**：在拦截器修改SQL时，可能在动态SQL中错误地引用了“delegate”属性，而实际参数中并不存在该属性，或者在参数中的路径引用不正确。 针对这些可能的原因，我需要给出相应的解决步骤： 1. **确认代理对象来源**：用户需要检查触发异常的Mapper方法调用处，确认传递的参数是否是预期的实体对象，还是被AOP代理的对象。例如，是否在Service层的方法中传递了`this`，而`this`实际上是一个代理对象。 2. **检查拦截器中对参数的访问方式**：拦截器在处理参数时，是否直接通过属性名（如`delegate`）访问，而没有考虑到参数可能是代理对象。需要确保拦截器中正确解析了参数的实际类型，并访问正确的属性。 3. **使用Spring AOP的CGLIB代理**：如果代理对象是JDK动态代理，可以尝试配置Spring使用CGLIB代理，这样生成的代理对象是目标类的子类，可能保留原始类的属性，减少反射问题。 4. **避免传递代理对象**：确保Mapper方法接收的参数是具体的实体对象，而不是被代理的Service或组件。例如，从代理对象中提取实际的业务数据再进行传递。 5. **检查自定义拦截器的实现**：用户的自定义拦截器可能在处理BoundSql时，错误地引用了参数对象的属性。需要检查拦截器中是否错误地拼接了SQL片段，引用了不存在的属性名。 6. **日志和调试**：建议用户开启MyBatis的完整日志，查看触发异常的SQL语句和参数，从而定位具体是哪个SQL操作导致了问题。同时，在拦截器中添加日志输出，打印参数的类型和内容，帮助确认问题所在。 另外，用户之前的问题可能已经涉及到了XML映射文件中的属性引用错误或参数未使用@Param注解的情况，但这次是在拦截器中，所以可能原因有所不同，需要更关注拦截器本身的实现和参数传递。 最后，可能需要用户提供更多的代码片段，比如拦截器的具体实现、触发异常的Mapper方法以及相关参数的传递方式，以便更准确地诊断问题。但基于现有信息，上述分析和解决方案应该能帮助用户逐步排查问题。</think>--- ### **问题根源定位** 你遇到的 `ReflectionException: No getter for delegate` 错误，本质是**MyBatis在解析参数对象时，无法通过反射找到`delegate`属性的getter方法**。结合自定义拦截器场景，核心原因通常是： 1. **拦截器处理了JDK动态代理对象**（如Spring AOP生成的`$Proxy`类），而代理类本身无`delegate`属性 2. **自定义SQL修改逻辑中错误引用属性路径**，导致尝试访问不存在的属性 --- ### **解决方案分步指南** #### **1. 确认拦截器作用对象** 检查自定义拦截器的`intercept()`方法，明确拦截的目标： ```java @Intercepts({ @Signature(type = Executor.class, method = "update", args = {MappedStatement.class, Object.class}) }) public class MyInterceptor implements Interceptor { @Override public Object intercept(Invocation invocation) throws Throwable { Object parameter = invocation.getArgs()[1]; // 获取SQL参数 // 此处parameter可能是代理对象，需特殊处理 return invocation.proceed(); } } ``` - **关键点**：若`parameter`是`$Proxy`实例，直接调用`parameter.getDelegate()`会失败 --- #### **2. 动态代理对象处理策略** **方案一：提取原始对象** 通过Spring AOP工具类获取代理背后的真实对象： ```java import org.springframework.aop.framework.AopProxyUtils; Object realTarget = AopProxyUtils.getSingletonTarget(parameter); if (realTarget != null) { // 使用realTarget替代parameter进行属性访问 } ``` **方案二：强制使用CGLIB代理** 在Spring Boot配置中禁用JDK动态代理： ```java @SpringBootApplication @EnableAspectJAutoProxy(proxyTargetClass = true) // 强制CGLIB public class App { ... } ``` --- #### **3. 检查SQL修改逻辑** 在拦截器中修改SQL时，避免硬编码属性名。例如： ```java // 错误示例：直接拼接delegate.id String newSql = "SELECT * FROM table WHERE delegate_id = #{delegate.id}"; ``` **修正方案**： - 若参数是Map，确保键名存在 - 若参数是实体，验证属性链有效性 ```java // 安全做法：先检查属性是否存在 MetaObject metaParam = SystemMetaObject.forObject(parameter); if (metaParam.hasGetter("delegate.id")) { // 安全使用属性路径 } ``` --- ### **实战案例演示** #### **错误场景还原** ```java // Service类（被@Transactional代理） @Service public class UserService { @Autowired private UserMapper userMapper; @Transactional public void errorMethod() { // 错误：传递this（实际是代理对象） userMapper.update(this); } } // Mapper接口 public interface UserMapper { void update(@Param("param") UserService param); } // XML映射文件 <update id="update"> UPDATE user SET name = #{param.delegate.name} <!-- 触发异常 --> </update> ``` #### **修正方案** ```java // 传递明确业务对象，而非代理对象 public void correctMethod() { User realUser = new User(); realUser.setName("test"); userMapper.update(realUser); // 传递原始POJO } // XML中引用正确属性 <update id="update"> UPDATE user SET name = #{name} <!-- 直接使用POJO属性 --> </update> ``` --- ### **高级调试技巧** #### **步骤1：打印参数实际类型** 在拦截器中添加日志，确认`parameter`的真实类型： ```java @Override public Object intercept(Invocation invocation) throws Throwable { Object parameter = invocation.getArgs()[1]; System.out.println("Parameter type: " + parameter.getClass().getName()); return invocation.proceed(); } ``` #### **步骤2：验证属性存在性** 使用MyBatis的`MetaObject`检查属性链： ```java MetaObject metaParam = SystemMetaObject.forObject(parameter); if (metaParam.hasGetter("delegate")) { Object delegate = metaParam.getValue("delegate"); // 进一步处理 } else { throw new IllegalArgumentException("参数缺少delegate属性"); } ``` #### **步骤3：依赖版本检查** 确保MyBatis核心与拦截器兼容： ```xml <!-- 推荐组合 --> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>3.5.13</version> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.1</version> </dependency> ``` --- ### **总结排查路径** 1. **拦截器入口**：检查`intercept()`方法获取的参数类型 2. **代理对象处理**：使用AopProxyUtils获取原始对象 3. **SQL属性引用**：通过MetaObject验证属性链有效性 4. **参数传递规范**：确保Mapper方法接收的是明确POJO而非代理对象 若问题仍未解决，建议提供以下信息进一步分析： - 自定义拦截器的完整代码 - 触发异常的Mapper方法及XML片段 - 完整的异常堆栈跟踪