我通常在工作机器上本地测试我的代码，然后将其移至开发环境，最后移至生产环境。在这种情况下使用调试/发布模式的最佳方法是什么？我只需要关心机器中的调试模式吗？我应该将调试模式或发布模式发布到开发吗？我知道可能我应该使用发布模式发布到生产。之前我并没有真正关注所有这些，所以我一直只在调试模式下工作，我知道我不应该这样做。
编辑：谢谢你的回答。看起来在我自己的机器中只使用调试模式是个好主意。即使它在开发机器中，它基本上向公众发布（同事，qa），因此它应该处于发布模式。当然，在发布到prod时它应该是释放模式。
答案 0 :(得分：12)
发布/发布应用程序时，您应该在发布模式下执行此操作。发布模式就是这样，释放应用程序。生成的代码通常性能更高，并且许多代码删除了许多与应用程序的开发阶段更相关的检查。
在典型的一天中，您应该在调试模式下进行开发。大多数语言将额外的检查插入调试模式应用程序。这些发现了更多的错误，但往往会减慢应用程序的速度。
但是，作为开发过程的一部分，您还必须对发布模式进行重要测试。客户实际上只会看到产品的发布模式版本，并且错误可能是特定于调试/发布模式的。在调试模式下插入的错误检查可能会引入隐藏应用程序中真正错误的副作用。
答案 1 :(得分：7)
我遵循这种方法：
所有测试必须至少在发布版本上进行，因为这是您要发布的内容。调试版本的分析通常是毫无意义的（特别是在C ++中），因为调试堆有很多额外的检查，完全改变了典型应用程序的性能配置文件。
答案 2 :(得分：3)
通常，始终将发布版本部署到生产中。调试将增加您的装配重量并降低性能。
如果您正在开发ASP.NET应用程序，则启用“调试”模式实际上会更改JIT编译器编译页面的方式/时间，并显着降低性能以增加更好的交互式调试功能。
至于要部署到开发的构建...如果您正在运行针对开发的单元测试，那么部署Debug构建可能是个好主意，这样您就可以在测试失败或发生异常时获得最多的调试信息。但是，希望有一个额外的测试或预生产环境，您可以在其中运行集成测试并在那里执行手动测试。 Testing / Pre-Prod环境应该完全使用Release版本，这样您就可以在进入Production之前看到真正的性能和编译问题。
如果您没有此中间测试/预生产级别，那么我建议您使用Release运行您的Dev环境。换句话说，您应该在发布配置中的生产之前运行至少一个级别。
有关您可以对配置执行的操作的更多信息，我有专门针对Silverlight的博客文章（http://blog.tonyheupel.com/2009/04/environment-specific-service-references.html）。有一个链接指向Scott Hanselman关于构建配置和不同环境的更通用的文章。
答案 3 :(得分：2)
默认情况下，将使用更多优化器开关编译发布版本，这将导致更快和更小的代码，这通常是您要发布给客户的名称（因此名称）。 Ť
调试构建几乎没有优化，这意味着在使用调试器时，底层机器代码更接近源代码，这有助于调试。此外，默认情况下，调试版本会插入额外的运行时代码检查，这些检查会捕获常见错误，例如访问未经初始化的数组成员。请注意，您可以使用调试符号构建发布版本，调试器很难将机器代码中的当前语句映射到适当的源代码行。