最稳妥获取Class对象的方式是obj.getClass()，它能准确反映运行时真实类型，避免子类重写或代理场景下的类型误判；ClassName.class在泛型擦除、类加载器隔离等情况下易出错。
Class对象怎么获取才安全可靠
直接用 obj.getClass() 最稳妥，比 ClassName.class 更能反映运行时真实类型，尤其在子类重写方法或代理场景下不会出错。泛型擦除后无法通过 list.getClass() 拿到泛型参数，这点必须提前有心理预期。
常见错误：用 String.class == "hello".getClass() 判断类型——看似成立，但遇到字符串常量池优化或模块隔离（如 JDK 17+ 的强封装）可能因类加载器不同而返回 false。应统一用 instanceof 或 isAssignableFrom() 做类型兼容判断。
- 动态加载类必须用
Class.forName("com.example.Foo")，注意它会触发静态初始化块 - 想跳过初始化就用
ClassLoader.loadClass("com.example.Foo") -
getClass().getDeclaredFields()只返回本类声明的字段，不包含父类；要全量得递归遍历getSuperclass()
反射读取私有字段和方法要注意什么
调用 setAccessible(true) 是绕过 Java 访问控制的唯一方式，但它在 JDK 12+ 默认被 SecurityManager 限制，在 JDK
InaccessibleObjectException。不是加了 try-catch 就万事大吉。
实操建议优先走标准 API：比如用 java.beans.Introspector 解析 getter/setter，或用 MethodHandles.lookup().findGetter()（JDK 7+）替代暴力反射。只有当目标类完全不可控（如第三方 jar 中无公开访问入口）时，才考虑反射。
- 修改 final 字段需额外调用
Field.set(obj, newValue)，但 JVM 不保证该修改对其他线程可见 - 调用私有方法前务必检查
method.getParameterCount() == args.length，否则抛IllegalArgumentException - 数组类型字段要用
Array.get(field.get(obj), index)读取，不能直接强转
Class.forName() 报 ClassNotFoundException 的真实原因
不只是类名写错。更常见的原因是：类在 classpath 中但被不同 ClassLoader 加载（如 Tomcat 的 WebAppClassLoader 和 SystemClassLoader 隔离）、模块未导出（module-info.java 里没写 exports com.example;）、或类依赖的某个接口/父类缺失。
调试时别只看异常栈顶，要逐层检查 getCause()。例如 ClassNotFoundException: javax.xml.bind.JAXBContext 在 JDK 9+ 是因为 JAXB 被移出默认模块，需显式加 --add-modules java.xml.bind 启动参数。
- 使用
Thread.currentThread().getContextClassLoader().loadClass(name)可规避部分类加载器问题 - Spring 的
ClassUtils.resolveClassName()内部做了多 ClassLoader 尝试，比裸调Class.forName()更健壮 - Android 上
Class.forName()对 lambda 生成的合成类名（如MyActivity$$ExternalSyntheticLambda0）可能失败，应避免反射这类名称
反射性能差到什么程度？哪些操作真该避开
单纯获取 Class 对象几乎无开销，但每次调用 Method.invoke() 或 Field.get() 比直接调用慢 5–50 倍（取决于 JVM 版本和是否 JIT 优化）。真正拖慢的是重复解析：反复调用 clazz.getDeclaredMethod("foo") 比缓存 Method 实例慢两个数量级。
容易被忽略的坑：Constructor.newInstance() 在 JDK 9+ 已被标记为 deprecated，推荐用 MethodHandles.Lookup 构造句柄并缓存，或直接用工厂方法。
- 高频场景（如 JSON 序列化）必须缓存
Method/Field引用，用ConcurrentHashMap存储 - 避免在循环内做
clazz.getMethod()，提取到循环外 - GraalVM 原生镜像（native-image）默认不支持反射，需提前用
reflect-config.json显式注册，否则运行时报NoClassDefFoundError
反射不是黑魔法，是暴露 JVM 底层契约的接口。用得好能解耦，用不好会让代码变成“运行时才报错”的定时炸弹。最危险的不是不会用，而是忘了它绕过了编译检查、泛型约束和模块边界——这些地方一旦出问题，堆栈信息往往指向毫无意义的 sun.reflect.NativeMethodAccessorImpl。
