默认情况下，rails 3.2设置active_record.mass_assignment_sanitizer = :strict在 config/environments/development.rb 中。（参见 railcasts 剧集http://railscasts.com/episodes/318-upgrading-to-rails-3-2）。这里是：
# Raise exception on mass assignment protection for Active Record models
config.active_record.mass_assignment_sanitizer = :strict
这使得mass assignment开发中容易出错并强制列出attr_accessible. 默认情况下这样做的原因是什么rails 3.2（还没有检查它是否也是rails 4）？
Baldrick 提供的链接现在似乎消失了。但是我最近阅读了一篇博客文章，它提供了关于 Rails 中批量分配安全问题的演变的非常有用的背景：http: //net.tutsplus.com/tutorials/ruby/mass-assignment-rails-and-you/
我不是这个问题的专家，但我的理解是：在 Rails 中错误配置批量分配可能会导致非常非常大的安全问题，现在它们已经普及，更加危险。Rails 4 试图通过要求您明确列出可以在控制器中大规模分配的字段来修补最大的威胁，这些字段很容易让您看到和处理安全问题。但是 Rails 3 中批量赋值的处理更加多变，并且在许多情况下，如果提交的参数不在 attr_accessible 白名单（或在黑名单）中，Rails 会简单地跳过该参数，而不让开发人员知道发生了任何错误。
这是一个问题。如果我正在编写一个需要高安全性（或者，这些天，任何级别的安全性）的应用程序，如果我编写了一个测试来确保某些参数被拒绝，我想知道它们被拒绝了。我宁愿早点而不是晚点找出 Rails 正在做什么，这样我就可以调整我的代码并相应地计划未来的站点部分。因此，该mass_assignment_sanitizen = :strict设置使这种更具声音的行为成为默认设置。
您说此设置使批量分配行为在开发中更“容易出错”，就好像这是一个问题。我认为您会希望您的 Rails 应用程序在开发和测试阶段尽可能容易出错和发声，以便您更快地了解代码中的更多潜在问题。所以我很欣赏 mass_assignment_sanitizer 默认值。
对我们俩来说幸运的是，Rails 4 通过更支持严格性的立场简化了这个问题。严格的质量分配参数清理，以及它的语音错误倾向，已成为控制器的默认功能（因为这个问题从一开始就从未真正属于模型），并为您提供了一个友好的私有功能，您可以在其中可以定义您需要的任何替代行为。