introspector.getbeaninfo() 有时拿不到属性是因为它仅识别符合javabean规范的getter/setter方法，且对方法签名严格敏感，如首字母大小写、布尔类型用isxxx而非getxxx、不捕获受检异常等。
为什么 Introspector.getBeanInfo() 有时拿不到你写的属性
Java 内省不是“自动扫描所有 public 字段”，它只认符合 JavaBean 规范的 getter/setter 方法，并且对方法签名极其敏感。比如 getUserName() 可以推导出 userName 属性，但 getusername() 或 GetUserName() 就不行——首字母大小写规则必须严格匹配 Introspector.decapitalize() 的逻辑。
常见错误现象：PropertyDescriptor 数组里没有你预期的属性，或者 getValue() 报 IllegalArgumentException: argument type mismatch。
- 确保 getter/setter 方法名完全遵循驼峰规范，且返回/参数类型与字段语义一致（如
boolean isActive()对应active属性，不是isactive） - 避免在 getter 中抛受检异常（
IOException等），内省会跳过这类方法；若必须抛异常，用运行时异常包装 - 如果类继承自父类且父类有同名 getter，子类未重写，则可能被父类方法覆盖，导致属性类型不匹配
Introspector.setBeanInfoSearchPath() 改了也没用？
这个方法只是设置内省查找 BeanInfo 类的包路径前缀（比如 com.example.MyBeanBeanInfo），但它不会影响默认的内省行为——只要没提供显式的 BeanInfo 实现，JDK 仍走标准反射推导流程。
使用场景：当你想为某个类定制属性描述（比如隐藏某些字段、改写 display name、绑定编辑器），才需要手写 BeanInfo 子类，并确保它在对应路径下可加载。
立即学习“Java免费学习笔记（深入）”；
- 路径必须是完整包名 + 类名后缀
BeanInfo，不能带$（匿名内部类不支持） - 该类必须有无参构造函数，且需继承
SimpleBeanInfo或实现BeanInfo接口 - 调用
setBeanInfoSearchPath()后，必须在获取BeanInfo前完成设置；线程不安全，多线程环境下建议只设一次且早于任何getBeanInfo()调用
性能差？别让 Introspector.getBeanInfo() 在循环里反复调用
Introspector 内部做了缓存，但缓存键是 Class 对象 + ClassLoader，一旦类被重复加载（比如热部署、OSGi、单元测试中反复 new URLClassLoader），缓存就失效，每次都会重新解析方法、生成 PropertyDescriptor 数组——这是典型性能黑洞。
实操建议：
- 把
BeanInfo缓存到静态 Map 里（key 是Class），尤其在工具类如 JSON 序列化、表单绑定中 - 避免在
toString()、hashCode()这类高频方法里触发内省 - 注意
Introspector.flushCaches()的副作用：它清空全局缓存，会影响其他模块；除非你确定类结构已变更且需要强制刷新，否则别轻易调
和普通反射比，PropertyDescriptor 的 readMethod 为啥常是 null
这不是 bug，是设计使然：PropertyDescriptor 构造时若只传了 readMethod 名（如 "getAge"），但目标类里找不到匹配方法，JDK 就会设为 null，而不是抛异常——它选择静默失败，后续调用 getValue() 才报错。
容易踩的坑：
- 不要假设
getPropertyDescriptors()返回的每个 descriptor 都有可用的readMethod或writeMethod，务必判空 - 对于布尔类型，优先检查
isXxx()而非getXxx()；但PropertyDescriptor不会自动 fallback，得自己处理 - 泛型擦除后，
readMethod.getGenericReturnType()拿不到真实类型，别指望靠内省还原泛型字段类型
内省真正的复杂点不在 API 多难记，而在于它把“约定”当契约——一个大小写、一个异常类型、一个类加载器，都能让整个链路静默断裂。写的时候多看一眼 PropertyDescriptor 里的 method 是否为 null，比事后 debug 十分钟强得多。
