经常会出现一些“无法再现”的缺陷报告，这些缺陷在您的计算机或软件项目中可能是可以再现的，但在供应商的系统上却无法再现。或者用户提供了复现步骤，但您本地却看不到该缺陷。当然，这种情况有很多变化，为了简化问题，我想了解的是：
贵公司对于“无法再现”的漏洞的政策是什么？将其搁置、关闭或忽略？我偶尔会遇到第三方框架中间断、无法再现的 bug，而这些问题几乎总是被供应商立即关闭……但它们确实是真正存在的缺陷。
您是否发现任何技术可帮助解决这些类型的 bug？通常我会从用户处获取系统信息报告和复现步骤，然后搜索关键字，尝试查找任何模式。
我正在开发一个网络项目，目前正在做与您技术非常相似的事情。我正在构建一个页面，可以引导用户收集信息，例如他们的浏览器版本和操作系统。我还将收集应用程序注册表信息，以便查看他们所做的事情。
这是一个非常真实的问题。我只能代表网站开发，但我发现用户很少能够给我需要查看问题的基本信息。我怀疑在其他类型的开发中也完全有可能做类似的事情。我的计划是继续改进这个系统，使其越来越有用。
但我的政策是永远不会因为无法重现而关闭错误报告，无论它有多么令人恼火。然后还有一些情况，当它不是一个错误，而是用户简单地感到困惑。这是另一种类型的错误，但同样重要。
你提到了一些在一些系统上可重现但在其他系统上却不一定的问题。处理这类问题较为简单：
第一步：通过使用某种远程软件，让客户告诉您如何在发生问题的系统上重现该问题。如果失败，则关闭它。
第二步：尝试在另一个系统上重现该问题。如果失败，则创建客户系统的精确副本。
第三步：如果仍然失败，则只能在客户系统上进行调试。
一旦您可以重现它，就可以修复它。不管是哪个系统都没有关系。
麻烦的问题是真正无法重现的问题，也就是只偶尔发生的事情。对于这种情况，您需要报告、日志和坚定的态度。
日志记录是你的朋友！
通常情况下，当我们发现无法重现的错误时，我们要么要求客户打开更多的日志记录（如果可用），要么发布一个版本，在我们感兴趣的区域周围添加额外的日志记录。一般来说，我们拥有的日志记录非常出色，并且具有非常详细的能力，因此很少发布带有额外日志记录的版本。
您还应考虑使用内存转储（我认为这也属于日志记录的范畴）。生成 minidump 非常快，通常可以在生产服务器上进行，即使在负载下（只要所产生的转储数量较少）。
我看问题的方式是：能够重现问题很好，因为它为您提供了一个可以更自由地进行调试、实验和操作的环境，但是 - 重现错误并不是调试它的必要条件！如果该错误仅在某个人的系统上发生，则仍然需要以相同的方式诊断和调试问题，只是这次需要更聪明地处理。
被接受的答案是最好的一般方法。在高层次上，值得权衡修复错误的重要性与您可以添加作为功能或增强的东西，这将使用户受益。一个“不可重现”的错误需要两天来修复吗？在那段时间内可以添加功能，以使用户获得比该错误修复更多的好处吗？也许用户更喜欢这个功能。作为开发人员，我有时会专注于我能看到的缺陷，然后要求用户反馈，而他们实际上都没有提到我能看到的错误，但该软件缺少了他们真正想要的功能！
有时，在调试过程中持续尝试重现错误可能是最有效的方法。为了使这种策略奏效，错误需要是“间歇性”的而不是完全“不可重现的”。如果您可以在10次中重复一次错误，并且对其最有可能发生的地方有想法，那么您可以在这些点放置断点，然后坚定不移地尝试重复错误并查看确切情况。我经常发现这比在一两个情况下记录更有效（虽然记录通常是我首选的方法）。
