在我的 Ruby (2.3.0) on Rails (5.0.1) 项目中，自动加载(和重新加载)通常工作正常。但是，在开发模式下，我偶尔会看到如下错误:

Unable to autoload constant Foo::Bar, expected /app/models/foo/bar.rb to define it

这是出乎意料的，因为:

1. 第一个请求运行良好(已经自动加载一次)。
2. 它仅在编辑代码并发送新请求后出现。
3. 它并不总是会发生。我不明白为什么有时无法重新加载。
4. 文件 (foo/bar.rb) 实际上定义了 Foo::Bar。

此外，foo/bar.rb 的代码非常简单:

module Foo
  class Bar < CustomRecord
  end
end

简单的解决方法是重新启动服务器，然后再次发送请求(总是成功)。 FWIW，我正在使用 zeus server .

我最好的猜测是没有重新加载某些东西，但我不确定如何进行调试。我似乎无法指出导致问题的任何具体操作。有时编辑代码会导致它发生，有时不会。

最佳答案

您可以找到一些关于 Rails 自动加载行为的很好的解释。 This answer提供了一个有用的解释，它从 this blog post at urbanautomaton.com 中获取.

总结:

基本上，Rails 首先使用 Ruby 的常量查找。如果失败，那么它有自己的查找，如果

• 它们不在自动加载路径中(如果 config.autoload_paths += %W(#{config.root}/foo) 不在，Rails 将找不到 app/foo/bar.rb添加到 config/application.rb)
• 未遵循目录名称/命名空间约定

如果定义如下，它将在 app/foo/bar.rb 中找到 Foo::Bar:

module Foo
  class Bar
  end
end

但不是

module Foo
  module Bar
  end
end

• 引用了不同命名空间中的常量，但没有在另一个已自动加载的文件中指示该命名空间

引用博文描述我的意思:

At this point, we’ve only seen how a single constant name maps to a single file name. But as we know, a constant reference in Ruby can resolve to a number of different constant definitions, which vary depending on the nesting in which the reference was made. How does Rails handle this?

The answer is, “partially”. As Module#const_missing passes no nesting information to the receiver, Rails does not know the nesting in which the reference was made, and it must make an assumption. For any reference to a constant Foo::Bar::Baz, it assumes the following:

module Foo
  module Bar
    Baz # Module.nesting => [Foo::Bar, Foo]
end

end

In other words, it assumes the maximum nesting possible for a given constant reference. The example reference is therefore treated exactly the same as the following:

Foo::Bar::Baz # Module.nesting => []

module Foo::Bar
  Baz # Module.nesting => [Foo::Bar]
end

While there’s been a significant loss of information, Rails does have some extra information it can use. It knows that Ruby failed to resolve this particular constant reference using its regular lookup, meaning that whatever constant it should refer to cannot be already loaded.

When Foo::Bar::Baz is referred to, then, Rails will attempt to load the following constants in turn, until it finds one that is already loaded:

• Foo::Bar::Baz
• Foo::Baz
• Baz

As soon as an already-loaded constant Baz is encountered, Rails knows this cannot be the Baz it is looking for, and the algorithm raises a NameError.

如果没有关于代码设置方式的更多细节，很难说出到底是什么导致了您的问题，但希望了解 Rails 中自动加载的情况可能会有所帮助。我强烈建议您阅读上面链接的博文和答案。

针对可能的解决方案进行编辑:

确保将“app/models/foo”添加到 config/application.rb 中的 autoload_load 路径 - 或者将“foo”移动到 app/models/concerns，默认情况下应该在那里。

经常添加显式的 require 语句会有所帮助——尤其是在开发中加载正确但测试中加载不正确的情况下。我最近通过添加一个需要我所有嵌套文件的文件(我有一个不反射(reflect)我的命名空间结构的目录结构)然后在我的测试助手中需要该文件来解决这个问题。

第二次编辑

包括与问题相关的信息，为什么常量可能只成功加载一次。

来自 the same blog post :

If constants are loaded only when they’re first encountered at runtime, then by necessity their load order depends on the individual execution path. This can mean that the same constant reference resolves to different constant definitions in two runs of the same code. Worse still, the same constant reference twice in a row can give different results.

Let’s go back to our last example. What happens if we call .print_qux twice?

> Foo::Bar.print_qux
I'm in Foo!
=> nil
> Foo::Bar.print_qux

NameError: uninitialized constant Foo::Bar::Qux This is disastrous! First we’ve been given the wrong result, and then we’ve been incorrectly told that the constant we referred to doesn’t exist. What on earth led to this?

The first time, as before, is down to the loss of nesting information. Rails can’t know that Foo::Qux isn’t what we’re after, so once it realises that Foo::Bar::Qux does not exist, it happily loads it.

The second time, however, Foo::Qux is already loaded. So our reference can’t have been to that constant, otherwise Ruby would have resolved it, and autoloading would never have been invoked. So the lookup terminates with a NameError, even though our reference could (and should) have resolved to the as-yet-unloaded ::Qux.

We can fix this by referring to ::Qux first, ensuring that it’s loaded for Ruby to resolve the reference:

> Qux
=> "I'm at the root!"
> Foo::Bar.print_qux
I'm at the root!
=> nil
> Foo::Bar.print_qux
I'm at the root!
=> nil

A funny thing has happened here. In order to get correct behaviour, we deliberately loaded the constant we needed before we used it (albeit indirectly, by referring to it, rather than loading the file that defined it).

But wait; isn’t this suspiciously close to explicitly loading our dependencies with require, the very thing autoloading was supposed to save us from?

To be fair, we could also have fixed the issue by fully qualifying all of our constant references, i.e. making sure that within .print_qux we referred to ::Qux and not the ambiguous Qux. But this still costs us our existing intuitions about Ruby’s behaviour. Moreover, without intimate knowledge of the autoloading process, we would have been hard pressed to deduce that this was necessary.

关于ruby-on-rails - 为什么 Ruby on Rails 在编辑代码后会虚假地引发 0​​x104567910？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41467451/