Java反射机制支持静态与动态工厂优雅切换，核心是解耦类型决策与对象创建：静态工厂提供类型安全API并可内部封装反射，动态工厂基于配置+反射实现运行时扩展，二者通过统一接口和策略链协同工作。
Java 反射机制在框架设计中实现静态工厂与动态工厂的优雅切换，核心在于解耦“类型决策”与“对象创建”，让框架既保有编译期可读性与性能，又具备运行时扩展能力。关键不是非此即彼，而是分层协作：静态工厂负责稳定、高频、已知类型的快速构建；反射驱动的动态工厂则兜底未知类型、配置化场景和插件化需求。
静态工厂作为默认入口，提供清晰语义和类型安全
静态工厂方法（如 Factory.createXxx()）应作为对外暴露的第一接口。它内部可封装反射逻辑，但对调用方完全隐藏——用户看到的是具名、无异常、泛型友好的 API。
- 例如：JsonSerializer.of(User.class) 表面是静态工厂，实际内部调用 Class.forName("com.example.UserJsonSerializer").getDeclaredConstructor().newInstance()
- 若类存在且已注册，则走轻量级缓存路径；若未注册，再触发反射加载备用实现，避免每次调用都查类路径
- 配合 @SerializeFor(User.class) 注解，在启动时扫描并预注册，把反射开销前移到初始化阶段
动态工厂基于配置+反射，支持运行时类型发现
当类型无法在编译期确定（如从 JSON 字段读取 class 名、从 XML 配置加载组件、SPI 插件加载），需启用反射驱动的动态工厂。
- 接收全限定类名字符串（如 "com.myapp.service.PaymentServiceV2"），通过 Class.forName(className) 加载，再用 getDeclaredConstructor().newInstance() 实例化
- 必须配合白名单校验或类加载器隔离，防止恶意类名注入（如 java.lang.Runtime）
- 建议搭配 ServiceLoader 或自定义 SPI 查找机制：先尝试加载 META-INF/services/com.myapp.FactoryProvider 中声明的实现类，失败后再 fallback 到反射
统一抽象层屏蔽差异，用策略模式协调两者
定义统一的工厂接口（如 ObjectFactory<T>），内部聚合静态策略与动态策略，由上下文决定使用哪一种。
立即学习“Java免费学习笔记（深入）”；
- 例如：Spring 的 BeanFactory 同时支持 getBean("name")（名称查找，可能触发反射）和 getBean(Class<T> type)（类型查找，优先走泛型推导+缓存）
- 可引入 FactoryResolver 策略链：先查本地缓存（静态注册）→ 再查注解元数据 → 最后执行反射加载，每步失败自动降级
- 关键点：所有策略返回相同接口实例，上层业务代码无需 if-else 判断工厂类型
规避常见陷阱，保障健壮性
反射虽灵活，但易出错。框架层面需主动防御：
- 类加载器一致性：动态加载时显式传入业务类加载器（Thread.currentThread().getContextClassLoader()），避免因双亲委派导致找不到类
- 构造器与访问控制：用 setAccessible(true) 绕过 private 限制，但仅限受信模块；生产环境建议强制要求无参公有构造器
- 异常标准化：将 ClassNotFoundException、NoClassDefFoundError、InstantiationException 统一封装为 FactoryCreationException，不向用户暴露底层反射细节
