核心是解决“参数如何来”而非仅调用构造器：反射只负责最后一步，依赖解析需手动设计逻辑或借助Spring等容器；轻量场景可硬编码规则递归创建，生产环境应对接成熟框架。
直接用反射调用带参数的构造函数创建对象不难，但处理“复杂依赖关系”时，单纯靠 Constructor.newInstance() 会很快卡住——因为参数本身可能不是基本类型或字符串，而是需要先创建的其他对象、配置、单例服务，甚至依赖注入容器管理的 Bean。
明确目标：不是“能调”而是“能解”
动态实例化有复杂依赖的对象，本质是解决“参数如何来”的问题。反射只负责最后一步“把参数塞进构造器”，前面的依赖解析必须由你设计逻辑支撑。
- 反射本身不管理依赖，它不读 Spring 配置、不查 Guice 绑定、也不自动递归创建嵌套对象
- 所谓“复杂依赖”，通常指：参数是接口类型、需从上下文获取、含生命周期管理（如 DataSource）、或需按条件选择实现类
- 因此重点不在
getDeclaredConstructor()怎么写，而在构造器参数列表拿到后，如何逐个准备实参
手动构建依赖链：适用于轻量级场景
当依赖不多、层级浅、且可预知时，可以写一个简易的参数解析器：
- 遍历构造器的
Parameter[]，用parameter.getType()获取每个参数类型 - 对每种类型硬编码规则：比如
DataSource.class→ 返回已初始化的 HikariDataSource；Properties.class→ 从 classpath 加载app.properties - 遇到自定义业务类（如
UserService.class），检查是否已有单例缓存，没有就递归用同样逻辑创建其构造参数 - 用
setAccessible(true)处理私有构造器，但仅限于你完全掌控的类，避免破坏封装
对接现有容器：推荐生产环境做法
真实项目中几乎不会手写完整依赖解析器。更合理的方式是借力成熟框架：
-
Spring 环境：用
ApplicationContext.getBean(Class<t> requiredType)</t>直接获取完整装配好的对象，无需自己调反射构造器 -
需要纯反射+容器辅助：先通过反射拿到构造器，再让 Spring 的
AutowiredAnnotationBeanPostProcessor或DependencyDescriptor帮你解析并填充参数值 -
无框架但需解耦：定义
ObjectFactory<t></t>接口，为每种关键依赖提供工厂实现，反射创建主对象时委托给对应工厂生成参数
避开典型陷阱
即使逻辑写对，运行时仍容易失败，注意这些细节：
-
Class.forName("x.y.Z")会触发类初始化（执行 static 块），若静态代码依赖未就绪的资源（如未加载的配置），会抛ExceptionInInitializerError - 构造器参数类型必须严格匹配：传
int却声明Integer，或传子类实例但构造器要求父类，都会报NoSuchMethodException - 使用
getDeclaredConstructor()后忘记调setAccessible(true)，私有构造器会因 IllegalAccessException 失败 - JDK 9+ 中
Class.newInstance()已废弃，必须用Constructor.newInstance()
