关键不是禁用反射，而是让注解读取“一次解析、多次复用、按需加载”：缓存Method/Field级注解实例，用ConcurrentHashMap+computeIfAbsent实现懒加载，禁用循环内重复getAnnotation，高频字段用MethodHandle绑定，精简注解结构，启动期生成静态元数据替代运行时反射。
在大厂代码评审中，反射链过长、注解提取频次高且未缓存，是接口吞吐下降的隐蔽元凶。关键不是禁用反射，而是让注解读取“一次解析、多次复用、按需加载”。
缓存注解对象本身，而非重复调用 getAnnotation()
每次 method.getAnnotation(XXX.class) 都会触发 JVM 创建动态代理、初始化 memberValues Map、执行安全检查——这些开销在 QPS 过万的接口中会迅速放大。评审时应重点确认是否已对 Method/Field 级注解做懒加载缓存。
- 使用 ConcurrentHashMap<Method, ApiEndpoint> 或 ConcurrentHashMap<Field, Validated> 作缓存容器，key 必须是 Method/Field 对象（它们重写了 equals/hashCode），避免字符串拼接 key 引发冲突或泄漏
- 通过 computeIfAbsent() 实现首次访问才解析，后续直接返回已构造好的注解实例
- 不缓存 Class 级注解到全局 map——类对象生命周期太长，易导致 ClassLoader 无法卸载；如需缓存，应配合弱引用或按业务域隔离
避免在请求链路中高频反射查找元数据
注解提取只是起点，真正拖慢吞吐的是后续反复调用 ann.value()、ann.roles() 等方法。每次访问都经由 InvocationHandler.invoke() 分发，仍是接口调用开销。
- 对超高频字段（如路由 path、鉴权 scope），用 MethodHandle 绑定注解实例，把属性读取压至 60 纳秒内
- 禁止在 for 循环、filter/map 链、或每请求必走的拦截器中重复调用 getAnnotation() —— 应提前在 Controller 初始化阶段或 AOP 切面入口完成提取并注入上下文
- 若框架支持热部署（如 Spring DevTools），需监听类重载事件主动清理对应 Method 的缓存项，否则旧类引用残留会导致内存泄漏
精简注解结构，减少嵌套与默认值膨胀
含 @Nested 注解、大量 default 值、或泛型丰富（如 Class<? extends Handler>[]）的注解，会显著拉长解析路径。JVM 不仅要加载注解类，还要递归解析其所有成员类型。
- 评审时检查注解定义：是否用到了非必要嵌套？能否将 @Validated(groups = {Create.class}) 拆为 flat 字段 validationGroup = "create"？
- 避免在注解中声明大型对象或数组，默认值尽量用字符串、枚举、基本类型，而非 new ArrayList<>() 或复杂配置类
- 对只读场景（如路由映射），优先用编译期注解处理器（APT）生成静态元数据类，彻底绕过运行时反射
用组合代替反射链，把注解解析移出核心路径
常见反模式是：Controller → 拦截器反射读注解 → 权限校验 → 再反射读另一组注解做参数校验 → 最后才进业务逻辑。整条链深度耦合反射，不可测、不可监控、不可内联。
- 将注解解析逻辑下沉到启动阶段，生成轻量级配置对象（如 RouteConfig、AuthRule），运行时只查表，不反射
- 用函数组合（pipe）串联处理步骤：parse → validate → auth → execute，每个环节输入输出清晰，可单独打点、mock、压测
- 导出解析后的元数据供 APM 工具采集，例如暴露 /actuator/annotations-cache-hit-rate，让性能问题可量化、可归因
