EL表达式${person.dog.name}如何识别person属性的Person类型

很多人会被getAttribute()返回Object类型的特性带偏，觉得必须提前拿到属性的实际类型信息才能访问嵌套属性，实际上EL的全流程都是基于Java运行时反射实现的，根本不需要提前预判对象类型：

• 第一步：定位根属性的实际对象
  按照EL默认的作用域查找优先级（page域 → request域 → session域 → 应用全局ServletContext域），调用findAttribute("person")拿到对应的对象引用。这里虽然方法返回值的声明类型是Object，但这个引用指向堆内存中实际实例的运行时类型是完全确定的——和你在Java代码里写Object obj = new Person()没有本质区别，你随时可以通过obj.getClass()拿到真实的Person类元数据，不存在类型信息丢失的问题。
• 第二步：动态识别类结构，解析第一层嵌套属性
  拿到"person"对应的实际对象后，EL容器根本不需要提前知道这个对象是什么类型，直接走固定反射流程：
  1. 调用当前对象的getClass()方法，拿到对象绑定的真实类信息——这就是你疑惑的“识别Person类型”的核心环节，所有类元信息都是从实例本身获取的，不需要额外的存储或前置查询
  2. 严格按照JavaBean规范，在当前类里匹配名为getDog()的公共无参方法（如果对应属性是布尔类型，会匹配isDog()的命名方法）
  3. 反射调用匹配到的getDog()方法，拿到返回的Dog实例引用，这个引用同样是Object类型，但直接指向堆里真实的Dog对象
• 第三步：递归完成下一层属性解析
  拿到Dog实例后完全重复上面的反射流程：提取Dog类的真实元信息，匹配对应的getName()方法，反射调用拿到最终的name属性值，整个${person.dog.name}的解析就完成了。

关键认知澄清 #

• 我们平时写Java代码需要强制类型转换，本质是编译期的静态类型校验要求，和运行时的实际类信息没有关系；EL是运行时动态解析的脚本逻辑，根本不走编译期的类型检查链路
• EL全程没有“提前知道person属性是Person类型”的前置环节：你可以做个简单测试，往session的"person"键里存一个普通字符串，再访问${person.dog.name}，容器会直接抛出“在java.lang.String类上找不到dog属性”的运行时异常——这就直接证明，EL是拿到实际对象后，才动态去匹配类结构的
• 对于List、数组、Map这类特殊集合结构，EL的解析逻辑也完全一致：拿到实际实例后通过反射匹配对应方法（比如Map的get(key)、List的get(index)），根本不需要编译期的泛型类型信息做支撑

内容的提问来源于stack exchange，提问作者Stefan