何时在名称空间上使用子域?即http://admin.foo.com VS http://foo.com/admin
或者，我也喜欢api.foo.com看起来与foo.com/api。我还发现，子域名设置有点棘手。
将另一个应用程序挂载到文件夹或子域中对于web服务器来说不是什么大问题，但是如果您的Rails应用程序同时包含/admin和普通应用程序，那么将其中一个应用程序作为子域提供服务就变得棘手了。
值得庆幸的是，Rails路由器在这方面非常灵活，并且很好地支持这两种场景。
TLDR: Rails通过路由引擎支持两种方式，在这一点上，它取决于个人偏好(尽管我怀疑子域选项不会与路径帮助器很好地发挥作用)
<<p> /admin路线/strong>为了实现/admin路由，Rails支持路由中的名称空间概念。在Rails应用中有/admin区域你只需在routes.rb中这样写:
namespace :admin do
resources :users
resources :posts
end
然后将/admin区域的控制器放在controllers/admin/中。类必须以Admin为前缀(如Admin::PostsController)。
由于大多数应用程序的管理区域很可能会与普通应用程序中的模型交互，因此可以肯定地说，使用名称空间是最方便的方法。
<<p> 子域名路线/strong>但是命名空间也可以与子域一起使用:
Rails路由器可以定义constraint块并在这些块中定义命名空间。如果你想将上面的命名空间托管在admin。example.com子域中你可以这样做:
constraints(:subdomain => /admin/) do
namespace :admin do
resources :users
resources :posts
end
end
(我不知道约束特性，但这篇博文似乎解释得很好)
这显然要求您配置web服务器，使其为同一个Rails应用程序提供admin.example.com和www.example.com服务。
我不确定会话(通过cookie实现)是否被延续，但我猜你可以弄清楚。
我认为另一个答案解决了实用性问题，但纯粹从安全角度来看:
在Rails安全指南中建议将admin放在子域中，因为它更能避免XSS攻击:
将管理界面放到一个特殊的子域，例如Admin.application.com并使其成为一个独立的应用程序用户管理。这使得盗取管理员cookie成为常态域名，www.application.com，不可能。这是因为一样的浏览器中的origin策略:一个注入(XSS)脚本www.application.com可能无法读取admin.application.com的cookie反之亦然。
因此，从安全的角度来看，将admin放在子域名中可能更安全。