CGLIBCallbackFilter方法代理控制详解

CGLIB 的 CallbackFilter 结合 setCallbacks() 能实现真正的方法级细粒度代理控制——不同方法可路由至完全隔离的 Callback 实例（如 MethodInterceptor、NoOp 或 FixedValue），而非低效的“统一拦截+if 分支”；但其核心陷阱在于 accept() 返回值必须严格对齐 callbacks 数组下标，一旦错位将导致日志误覆盖、功能静默失效甚至运行时异常，因此务必采用下标常量化、兜底日志和纯字符串匹配等实践来保障可靠性、可维护性与高性能。

直接回答：用 CallbackFilter 配合 setCallbacks()，在 accept() 方法里根据 Method 对象返回不同下标，就能让不同方法走不同的 Callback 实例——不是“统一拦截再 if 分支”，而是真正隔离的执行路径。

CallbackFilter.accept() 返回值必须严格对应 callbacks 数组索引

这是最容易出错的地方。很多人写 accept() 时随手返回 0 或 1，却没核对 setCallbacks(new Callback[]{cb1, cb2}) 的顺序。

• return 0 → 一定触发 callbacks[0]，也就是数组第一个元素
• return 1 → 触发第二个，以此类推
• 如果方法名匹配不到任何分支，又默认 return 0，那所有漏掉的方法都会误入第一个回调（比如全被日志拦截器包住）
• 建议在 accept() 末尾加兜底日志：System.err.println("no callback assigned for " + method.getName());，避免静默走错逻辑

常见误用：把 MethodInterceptor 当万能回调，忽略 NoOp / FixedValue 等语义差异

Callback 不是只有 MethodInterceptor 一种。混用类型时，accept() 返回的下标若指向了 NoOp.INSTANCE，该方法就完全不执行原逻辑；若指向 FixedValue，则直接返回固定值，连 invokeSuper() 都不会调。

• MethodInterceptor：适合加日志、事务、权限等需要“前后增强+调用原方法”的场景
• NoOp.INSTANCE：适合禁用某个方法（比如测试环境屏蔽支付），但要注意它不抛异常，调用方收不到任何提示
• FixedValue：适合 mock 返回值（如缓存命中直接返回），注意其 loadObject() 返回值类型必须和方法签名一致，否则运行时报 ClassCastException
• 别在同一个 callbacks 数组里混用不兼容的 Callback 类型，比如给 void 方法配 FixedValue，会直接失败

性能与兼容性：accept() 方法本身不能重，且需避免反射或 IO

accept() 在每次方法调用前都会执行，是代理链的第一道关卡。它的开销直接影响整体性能。

• 禁止在 accept() 里做 method.getAnnotation() 这类反射操作——JVM 不会缓存结果，反复解析字节码很慢
• 更推荐用方法名字符串匹配（method.getName().equals("xxx")），或提前把注解信息缓存在 static Map 中
• JDK 17+ 上，如果目标类用了 sealed class 或强封装模块，method.getDeclaringClass() 可能抛 InaccessibleObjectException，此时只能靠名字匹配保底
• 别在 accept() 里打完整堆栈或写文件，高并发下 I/O 会拖垮整个代理调用

真正难的不是写通逻辑，而是当业务方法越来越多、拦截策略越来越细时，accept() 里的分支判断会变成隐式状态机——没人记得清哪个下标对应哪个业务含义。建议把下标常量化（如 public static final int AUTH_CALLBACK = 0;），并在 setCallbacks() 处加注释说明每个位置的职责，否则半年后你自己都得重读源码才能改 Bug。

今天关于《CGLIBCallbackFilter方法代理控制详解》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！