Namespace, Class, and Variable Name Precedence

同学们，今天我们来看一个Apex解析器的小秘密：当代码里出现名字冲突时，它到底怎么判断谁是变量、谁是类、谁是命名空间。 大家想想，你写了一个表达式，比如 `myVar.field`，那解析器首先要搞清楚 `myVar` 是什么。问题来了——你完全可以定义一个局部变量叫 `Account`，同时也有个类叫 `Account`，甚至还有个命名空间叫 `Account`。解析器遇到 `Account` 的时候，它不会头疼，因为它有固定的优先级顺序： ，第一优先，局部变量。， ，第二优先，类名称。， ，最后才看命名空间。， 也就是说，只要当前代码块里存在一个叫这个名字的局部变量，解析器立刻就把它认作变量，后面的点号就在这个变量的“域”里继续查找字段。只有在没有这个局部变量时，它才去翻类列表，把它当成类来处理。类也没有？那才轮到命名空间。 这个顺序不仅适用于字段访问，方法调用也同样遵循。比如 `something.method()`，解析器会把 `something` 先当局部变量，把 `method` 当成它的方法；如果不是局部变量，就检查 `something` 是不是类名，那么 `method` 就被解释为静态方法；再不是，才往命名空间去找。 更关键的一点来了：一旦解析器确认了前面这段的身份，比如它已经明确 `sBody` 是一个局部变量，那么整个表达式的上下文就“锁定”在了这个变量的内部。后面无论你打多少个点，都只能在这个变量的结构里找字段，不能再跳回 Apex 的其它元素。换句话说，`sBody` 后面的字段名称，永远不可能再去代表一个类、一个命名空间或者一个独立的Apex表达式。 打个形象的比方：你回到家门一开，解析器认出了你家门牌号是“卧室”，那么进去之后，你看到的衣柜、床铺都只能是这个卧室里的东西，不会突然变成隔壁教室的黑板。代码里，`sBody.Field__c` 的 `Field__c` 就只能是 `sBody` 这个对象的一个字段，绝不会被解释成一个叫 `Field__c` 的类或者命名空间了。 所以，记住三句话： ，先局部，再类，最后命名空间；， ，方法调用同样套路；， ，一旦踩进变量的地盘，后面就乖乖只看字段，别想跨界。， 好，这个要点就讲到这儿，大家可以在练习里故意起几个同名变量感受一下解析的优先级，加深理解。