java反射setaccessible(true)不生效因安全管理器拦截或jdk模块限制；beanutils映射易丢字段；反射类型转换易classcastexception；高频反射影响gc；应缓存field/method并慎用。
Java 反射调用 setAccessible(true) 为什么有时不生效
因为目标字段或方法被安全管理器（SecurityManager）拦截，或运行在强限制环境（如某些 JDK 17+ 模块系统默认策略下）。反射绕过访问控制的前提是 jvm 允许——不是代码写了就一定成功。
- JDK 9+ 模块系统中，若目标类不在
opens或exports范围内，setAccessible(true)会抛InaccessibleObjectException - spring Boot 3+ 默认启用
--illegal-access=deny，需显式加 JVM 参数：--add-opens java.base/java.lang=ALL-UNNAMED - android 上从 API 28 开始，非 SDK 接口调用会被静默失败或抛
IllegalAccessException，反射读私有字段基本不可靠 - 示例：对
private final String value字段设值前，必须先检查field.trySetAccessible()返回值，不能只依赖setAccessible(true)
用 BeanUtils.copyProperties 做异构对象映射时字段丢失
apache Commons BeanUtils 默认只拷贝 public getter/setter 方法对应的属性，且严格按方法名推导字段名；遇到 Lombok @Data、kotlin data class、或字段名含下划线（如 user_name）时极易漏拷。
- 源对象字段为
userName，但目标对象写成user_name→ 不匹配，不拷贝 - Lombok 生成的
isXxx()方法（如isActive()）在 BeanUtils 中可能被识别为布尔属性active，但目标类若定义为Boolean xxx就无法对齐 - 避免用
BeanUtils处理命名不规范或跨语言结构，改用mapStruct（编译期生成）或手动映射 +Field.get()/Field.set() - 调试时可先调用
PropertyUtils.getPropertyDescriptors(src.getClass())看实际识别出哪些属性
反射遍历字段做类型转换时 ClassCastException 频发
反射拿到的字段值类型和预期不一致，尤其当源字段是泛型擦除后的原始类型（如 List）、或存在自动装箱/拆箱（int vs Integer）、或 json 序列化后反序列化为 LinkedHashMap 时。
- 从 JSON 字符串转成
Map再用反射塞入 POJO，所有数字字段默认是double，直接field.set(obj, value)会报错 - 解决办法：先用
field.getType()判断目标类型，再做显式转换 ——Long.class.equals(field.getType())时调((number)value).longValue() - 不要信任
field.get(obj)返回值的运行时类型，它只反映 JVM 实际存储的引用类型，不等于声明类型 - 第三方库如
Objenesis创建无参实例时，字段初始值为NULL或 0，后续反射赋值前务必校验非空
高频调用反射导致 GC 压力大、响应变慢
每次 Class.getDeclaredField() 或 Method.invoke() 都触发内部缓存查找和安全检查，短生命周期对象频繁反射会显著抬高 Young GC 频率，尤其在网关类服务中。
- 缓存
Field和Method对象（用ConcurrentHashMap<class map field>></class>），避免重复getDeclaredField -
Method.invoke()比field.set()开销更大，能用字段直写就别走 setter - JDK 16+ 可启用
-XX:+UseFastUnorderedAccess优化反射字段访问，但仅对非 Static、非 final 字段有效 - 真正高吞吐场景（如每秒万级消息转换），反射应退居为 fallback 方案，主路径用代码生成（
ByteBuddy）或预编译映射逻辑
反射不是银弹，它把类型检查从编译期挪到运行时，代价是更难 debug 的异常、更隐蔽的性能拐点、以及模块化和安全策略带来的不确定性。写通用转换网关时，宁可多几行明确的 if-else 映射，也别让反射成为唯一抽象手段。