应拆解反射：缓存Class.forName()等耗时操作，初始化阶段预解析字符串查找，避免循环内调用；用MethodHandle替代Method.invoke()降开销60%，字段访问优先索引而非名称匹配，注解解析移至类加载期。
不能靠“选一个”，得把反射拆开用：该缓存的缓存，该硬编码的硬编码，该拦截的提前拦截。灵活性和性能不是非此即彼的选项，而是同一段代码里不同层级的取舍。
哪些反射操作必须提前缓存
每次调用 Class.forName()、clazz.getDeclaredMethod() 或 field.setAccessible(true) 都触发类加载、安全检查和元数据解析——这些是纯运行时开销，且无法被 JIT 优化。
- 所有基于字符串查找的操作（如
getMethod("save")、getDeclaredField("id")）必须在初始化阶段执行一次，结果存进static final Map<String, Method>或ConcurrentHashMap - 若类型由配置驱动（如
payment.impl=AlipayProcessor），应在 Spring Bean 初始化时完成Class.forName().getDeclaredConstructor().newInstance()，而不是每次请求都重做 - 避免在 HTTP handler 或数据库 mapper 循环体内调用
obj.getClass()—— 同一 handler 处理的往往是同一种 DTO，Class对象可复用
字段/方法访问时怎么绕过字符串匹配
FieldByName 在 Go 是性能黑洞，在 Java 里 getDeclaredField("xxx") 同样线性扫描 + 字符串比对，20 字段 struct 下慢 5–8 倍是常态。
- 字段名固定时，直接用索引：比如已知
id是第 0 个字段，就写fields[0].set(obj, value)，跳过名称查找 - 字段带注解（如
@Column(name="user_id")），解析注解逻辑必须放在类加载期（static块或@PostConstruct），而非每次反序列化都重读 - 用
MethodHandle替代Method.invoke()：它能被 JVM 内联，实测调用开销降低 60% 以上，但要求 JDK 7+
CanSet / isValid / setAccessible 这些检查能跳过吗
不能跳。漏掉任意一个，不是 IllegalAccessException 就是 NullPointerException，而且往往发生在高并发或边缘 case 下，极难复现。
-
field.setAccessible(true)必须在缓存前调用一次，之后反复使用该Field实例即可，不要每次设值都调 - 修改字段前必加
if (field.get(obj) != null && field.canAccess(obj))—— 尤其当 obj 是子类实例、字段被子类覆盖时，canAccess可能返回 false -
Method.invoke()前检查method.getParameterCount() == args.length，否则IllegalArgumentException会吞掉真实错误上下文
动态代理 vs 纯反射：什么时候该换方案
当你发现自己在反复做「根据字符串找类→找方法→校验参数→调用→包装异常」，说明反射已沦为胶水代码，该升级了。
- 统一入口场景（如 API 路由分发、规则引擎执行），用
InvocationHandler+ 接口代理，把反射逻辑收口到invoke()里，上层只认接口 - ORM 字段映射、JSON 反序列化这类高频路径，直接生成字节码（如 ByteBuddy）或编译期注解处理器（APT），彻底消灭运行时反射
- 测试中需访问私有字段？优先用
@TestInstance(TestInstance.Lifecycle.PER_CLASS)配合 package-private + 同包测试类，比反射更轻量、更稳定
真正难的不是“用不用反射”，而是识别出哪一行代码正在为灵活性支付不可接受的性能税——那行代码通常藏在循环里、嵌套深的 if 分支中，或者被日志打印语句包裹着，看起来无害，实则每毫秒都在拖慢整个链路。
