反射需谨慎使用：必须校验权限与类型，禁用不可信类加载，分类处理异常，泛型信息获取要小心。生产环境应限制私有成员访问，避免动态拼接类名，优先复用框架封装能力。
反射不是万能钥匙，用错地方反而锁死系统
macOS 微信消息自动化工具。通过 GUI 自动化实现：发送消息给指定联系人、读取聊天内容、监控新消息。适用于需要自动化微信操作的场景，如定时发送、批量回复、消息备份等。依赖 peekaboo 进行屏幕截图和 UI 交互。仅支持 macOS。开源地址：https://github.com/chairmanmia...
反射调用前必须校验权限与类型
Java 的 AccessibleObject.setAccessible(true) 能绕过访问控制，但不等于可以随意调用。生产环境应严格限制私有成员的反射访问，尤其避免在序列化、RPC 或通用工具类中无差别开放。建议：
• 先用 Modifier.isPublic() 或 getDeclaredMethod() + 显式 try-catch 判断是否存在且可访问
• 对非 public 成员，仅在明确业务需要（如 ORM 字段映射、测试 mock）时临时启用，并记录日志
• Spring、MyBatis 等框架内部已做封装，业务代码尽量复用而非自行反射操作
避免反射加载不可信类或动态字节码
通过 Class.forName() 或自定义 ClassLoader 加载运行时拼接的类名，极易引发类注入或远程代码执行。常见风险场景包括：配置项传入类名、URL 参数解析后反射实例化、模板引擎中嵌入表达式。建议：
• 禁止从用户输入、配置文件、HTTP 参数直接构造类名字符串
• 如需动态加载，限定白名单（如枚举或预注册的处理器类），并用 ClassLoader.loadClass() 替代 forName()（后者会触发初始化）
• 不使用 Unsafe.defineAnonymousClass() 或 Instrumentation.redefineClasses() 等高危 API
反射异常需分类处理，不能只吞掉
IllegalAccessException、InvocationTargetException、NoSuchMethodException 表示不同层级的问题，统一 catch (Exception e) 会掩盖真实缺陷。建议：
• NoSuchFieldException / NoSuchMethodException 多为代码演进导致，应作为编译期检查缺失的信号，配合单元测试覆盖
• IllegalAccessException 说明访问控制策略生效，需确认是否应放宽权限或改用标准 API
• InvocationTargetException 的 cause 才是真实业务异常，必须 unwrap 并按语义处理（如重试、降级、告警）
泛型擦除下反射获取类型信息要谨慎
运行时无法直接拿到泛型实际类型（如 List<string></string> 擦除为 List），但可通过 Method.getGenericReturnType() 或 Field.getGenericType() 获取带泛型的 Type。注意：
• ParameterizedType 需手动 cast 并调用 getActualTypeArguments()，否则仍得 Object
• 匿名内部类、Lambda 表达式可能丢失泛型信息，不要依赖其反射结果做类型强转
• Gson、Jackson 等库已内置泛型解析逻辑，业务层优先用它们的 API，而非手写 TypeReference
