Ruby 的常量查找路径问题是一直困扰我的一个问题，在工作中遇到过好几次，一直没有彻底弄清楚到底为什么，最近在读一本书《Ruby 元编程》，对 Ruby 对象模型有了更深入的认识，另外读了一篇 blog《Everything you ever wanted to know about constant lookup in Ruby》, 让我总算把 Ruby 常量查找路径这个问题搞得比较清楚。 [b]第一个遇到的问题，我还曾经在 Ruby-China 上发过帖。 [/b] 输出结果是 这是我在重构薄荷网代码时候遇到的问题，method1 和 method2 都是常见的类方法的定义方面，我向来认为它们是等价可替换的写法，但是从实际执行的结果看，它们里面的常量查找路径不一样。 如果我把 M1 的定义改成下面的样子： 执行结果是： [b]还有一个问题是也是经常遇到的，抽象成问题代码如下： [/b] 会报异常： [b]Ruby 常量查找时依据两条路径[/b] A. Module.nesting B. open class/module 的 ancestors A 比 B 优先，A 找不到了才到 B 中查找。 A.Module.nesting 的概念比较容易理解，它是指代码位置的 module 嵌套情况，它是一个数组，从最内层的嵌套一直到最外层的嵌套，如果没有嵌套，数组为空。任何一处代码位置都有 Module.nesting 值，可以通过下面的代码打印出各个位置的 Module.nesting 值。 输出是： 大家有没有注意到，module A::B 这种快捷写法会导致 A 不在 Module.nesting 里，这就是上述第二个问题的根源，因为 M 是 A module 下的常量，module A::B 写法导致不会查找 A::M。 说完 A Module.nesting，再说一下 B open class/module 的 ancestors，这个问题相对复杂很多。简单的说，在 Ruby 代码的任何位置，都有一个 self 存在，同样也有一个 open class/module 存在，在模块和类定义处，它通常就是对应的模块和类，在方法内部，它是方法对应的类。对于 ancestors，我们可以通过代码位置 open class/module 的 ancestors 方法取得。 （备注：ancestors 在引入 singleton_class 概念之后变得有点复杂，如不清楚可参考《Ruby 元编程》） 上述第一个问题： 在method1 中 A 是 [C1] open class/module 是 C1，所以 ancestors 是 [C1, M1, Object, Kernel, BasicObject] CK 在 A 可以找到，CT 在 B 可以找到。 method2 中 A 是 [C1] open class/module 是 C1 的 singleton_class , 所以 ancestors 是 [Class, Module, Object, Kernel, BasicObject] CK 在 A 可以找到，CT 在 A 和 B 都找不到。 对于 可运行，是因为这时，在 method2 中，open class/module C1 的 singleton_class 扩展了 M1，所以 ancestors 变成了 [M1, Class, Module, Object, Kernel, BasicObject]。 至此，这两个困扰我多时的问题终于彻底搞清楚了。这个过程给我的一个体会是：面对技术上的一些疑问，如果只是浅尝辄止，是永远不能够真正掌握它的，只有深入专研，透彻理解它的原理，才能够真正掌握它，获得真正的能力提升。