rails 4.2 web控制台gem是否完全取代了better_errors gem，或者我需要查看每一个的功能来确定我更喜欢哪一个？
它们不是一回事。。网络控制台甚至在其自述文件上推荐更好的错误：
查看better_errors作为任何机架应用程序的绝佳替代方案！
web控制台的优点是，您可以在文件或视图中的任何位置启动一个调用debug的控制台会话，就像binding.pry（来自pry-gem）一直以来所做的那样。
better_errors是一个改进的错误屏幕，它恰好在侧边栏上有一个控制台会话（如果您使用binding_of_caller gem）。
IMO，你可以同时使用这两个宝石。。不需要选择一个或另一个。
TL；DR：错误越多越好。
我不同意这里公认的答案。主要是因为建议的差异不是真实的。
在任何您想要的地方触发一个better_errors控制台总是很简单的，就像raise 'bang'一样简单。您在想要的位置抛出一个异常，控制台就会在该上下文中启动。您可以在任何文件或视图中引发异常，并在该上下文中获得控制台。
我不确定公认的答案是否意味着web_console不会在异常时触发，这就是他建议使用这两个gem的原因，但无论如何，现在确实web_consol也会触发异常。
因此，如果没有功能差异，那么，首先，运行两个gem是没有意义的。事实上，我预计会发生冲突，尽管可能只是取决于哪一个先发现了异常。
第二，真正的区别在于，错误越多越好。看看这两张照片的截图。web_console只是一个标准的rails异常页面，下面有一个裸露的黑色终端。如果你想知道本地或实例变量，你必须用控制台检查它们。better_errors（至少在我看来）有一个风格漂亮得多的页面，但更重要的是，它显示了调用堆栈（包含紧凑或完整的列表），它在控制台上方为您提供了触发代码列表，然后在控制台下方列出了请求/本地/实例变量，这通常可以解释问题所在，而无需在控制台中执行任何操作。这是一堆额外的、有用的功能，web_console没有遗漏任何东西（除非极简主义是你的包）。
我不知道为什么37Signals/Basecamp或Rails团队决定合并web_console而不是better_errors。也许是出于设计理念/架构的原因，他们希望与它保持一定的距离，也许他们认为它的功能太全面，无法自动包含在内。有些人似乎认为37Signals非常喜欢内部构建或可以在内部使用的东西，也许这是唯一的原因。
自从Thiago发布后，其他发生了变化的事情是，正如marklar所说，你现在用console而不是debug启动web_console，并且web_consol在其GH自述中不再建议将better_errors作为替代方案。