内部调用绕过spring aop代理是因为this.xxx()直接调用原始对象，不经过代理，导致@cacheable等注解失效；需通过@enableaspectjautoproxy(exposeproxy = true)启用aopcontext.currentproxy()手动获取代理对象调用，或采用拆分service、自注入、独立缓存组件等更稳妥方案。
内部调用为什么绕过Spring AOP代理
Spring的@Cacheable、@Transactional等注解依赖AOP代理生效，但同一个类里的方法调用（即内部调用）是直接走this.xxx()，根本不会经过代理对象——所以Redis缓存压根不会触发。
典型现象：方法getUserById(Long id)加了@Cacheable，但在同个Service里被loadUserWithProfile()直接调用，结果每次都是查库，缓存形同虚设。
- 本质是Java方法调用机制问题，不是Spring配置或Redis配置错
- 即使开启
expose-proxy="true"，this指向的仍是原始对象，不是代理 - 哪怕用CGLIB代理，内部调用照样不进拦截器链
AopContext.currentProxy()怎么安全用
Spring提供AopContext让类能“手动拿到当前代理对象”，从而把内部调用转成代理调用。但它默认关闭，必须显式启用，否则抛IllegalStateException: Unable to retrieve current proxy。
启用方式只有一处：@EnableAspectJAutoProxy(exposeProxy = true)（Java Config）或<aspectj-autoproxy expose-proxy="true"></aspectj-autoproxy>（XML）。漏掉这步，AopContext.currentProxy()必崩。
- 只能在被代理的Bean内部使用，比如Service类里；在Controller或工具类里调用会返回null或异常
- 类型要强转准确，例如
(UserService) AopContext.currentProxy()，不能只转成Object - 若Service实现了多个接口，需按实际注入类型转换，否则ClassCastException
替代方案：比AopContext更稳的三种做法
依赖AopContext.currentProxy()会让代码和Spring AOP耦合变深，且容易因代理类型（JDK/CGLIB）或泛型擦除出问题。生产环境更推荐以下方式：
- 拆方法到另一个
@Service类里，让跨Bean调用天然走代理（最简单，也最符合单一职责） - 手动注入自身Bean（
@Autowired private UserService self;），前提是该Bean是单例且非构造注入循环依赖场景 - 缓存逻辑抽成独立组件，比如
CacheLoader<long user></long>，由业务方法显式调用cache.get(id)，彻底脱离AOP生命周期
示例：用自注入避免AopContext
@Service
public class UserService {
@Autowired private UserService self; // 注意：不能用this，也不能在构造器里用
public User loadUserWithProfile(Long id) {
return self.getUserById(id); // 走代理，@Cacheable生效
}
@Cacheable(key = "#id")
public User getUserById(Long id) {
return userMapper.selectById(id);
}
}
为什么CGLIB代理下AopContext.currentProxy()有时返回null
不是所有CGLIB代理都会把AopContext设进去——只有目标类被Spring真正以CGLIB方式代理时才有效。如果类有接口、且Spring配置了proxy-target-class="false"（默认），它就走JDK动态代理，此时AopContext.currentProxy()仍可用；但如果因为某些原因（如缺少无参构造、final方法）导致CGLIB代理失败回退，或用了@Primary覆盖了默认代理策略，就可能拿不到代理。
- 调试时可打日志：
System.out.println(AopContext.currentProxy().getClass())，看是不是$$EnhancerBySpringCGLIB或$Proxy开头 - 若返回null，优先检查是否漏了
expose-proxy="true"，再确认Bean是否真被代理（比如是否被@Lazy或条件化配置跳过） - final类、final方法、private方法无法被代理，这类方法上加
@Cacheable永远无效，别白费劲
真实项目里，内部调用缓存失效的根本原因往往不在Redis或AOP配置，而在对代理边界缺乏感知。一旦开始用AopContext，就得同步处理类型转换、空指针、代理失效这几道坎。
