a) 我所谓的“被迫调试一个自己从来没见过的问题”，一般指调试完全不是自己写的代码。程序员可能会对大体概念上有些了解，而对很多细节（数据结构、算法，甚至代码的框架选择）一无所知。这种情况最典型地出现在接手别人的工作时。在一些极端情况下（取决于原先的代码质量），这种情况甚至可能伴随整个工作过程。

b) 其实我和前面几位的观点并无实质差别。Log和debugger作为工具而言并无高下之别，只看是否适用，但我更希望明确地表述“究竟什么是合适做选择的时候”，而不是泛泛地讲“合适的时候选择合适的工具”。

后来我私下和东哥在MSN上重新聊了一次，表达上有些改变。我比较倾向于这样组织我的看法：log和debugger虽然理论上范围没有明确的界限，但各自有各自更适合的领域。我喜欢把一个调试的过程主要分为两个解决：

a) 从完全不知道目标（只看到程序执行不正常），到大约知道目标会在哪个模块（比如一个DCOM控件失败，我是该怀疑COM runtime，还是主调程序，还是被调程序）；
b) 从大约知道在哪个模块到确定到问题的根源。

前者是宏观的定位，后者则是微观的定点打击。我的观点是log在我的个人实践中更适合在场景a)帮助程序员缩小怀疑范围——因为有时候一个bug涉及多个模块甚至多个产品，没法一个个调试；而debugger则适合在场景b)帮助找到最终根源——因为到这个阶段的时候程序员已经能把怀疑范围固定到一个进程里了。所以我不是很喜欢把这两者拿来对比。

我们很多时候没有注意这两者的分别，是因为调试过程中还有程序员知识的存在。很多程序员不愿意在开发阶段考虑log，很大程度上是因为他们自己可以通过自己对代码的了解弥补工具的不足，所以我们经常能看到一个程序员拿log或者debugger包打天下的情况。

但是，当程序员被迫去调试一个自己从来没有见过的问题时，这两个工具的差异就体现出来了：log的粒度更粗（所以程序员才会去急急忙忙地加printf，为的就是显示微观信息），但是它的表述更具描述性；debugger粒度细，可以精确到每个变量，却无法在宏观上反映模块间的执行流程。这种情况下如果非要让两者互相替代，只能是吃力不讨好。

至于是否干扰执行呢，确实是要看具体的bug是不是会被影响而定的。我是针对东哥前面说的UI而言的。就我的经验来说，UI程序是非常典型的debugger严重干扰执行流进而干扰问题分析的场合。我曾经处理过一个Windows环境下由于钩子函数性能问题导致在切换窗口中消息派发错误的问题。那个例子是非常典型的无法使用调试器的场景，因为任何情况下执行流程被断下都会导致消息传送错误，结果就是一旦上调试器几乎100%无法重现。

这两个都可以解决问题，但是在不同的场合有不同的优势，本来就是哪个合适用哪个，何必拘泥？

至于cppof286提到的b、c两点，我个人是非常赞同的。

至于a有保留意见，是否干扰执行并不重要，如果可以诊断出问题，是否干扰了执行无所谓。如果干扰导致不能诊断问题，那自然就不用这个方法好了，算不上什么禁招。

这么写我这里不行啊， 调起来了 但是是自带的filemerge 不是p4merge 怎么回事啊？

a) UI调试适合使用debugger：在Windows下我旗帜鲜明地反对这一点。现今流行的Windows UI framework对多线程和事件等待的依赖过于强烈，任何随意设置断点的行为都可能影响程序的执行过程，这种条件下设置断点是典型的禁招。

b) 至于远程调试帮助解决UI调试问题——这是另一个问题 。很早以前WinDBG就已经发展出了-remote和-premote两种远程调试法。

c) 补充一个个人观点：就我目前所经历的所有情况看，认为log没有debugger好用人都往往自己假设了一个基本前提，就是代码原来没有信息输出，出错了才开始急急忙忙地加printf调试。在我看来这个不叫log，只能叫临时抱佛脚。——Debugger比这种“log”好用是必然的，因为这种情况下程序员的任务是从无到有地构造探查范围，Debugger的call stack和断点比printf好用得多。

合理设计的log应该是一开始就内嵌在系统里的，它的所有开销必须是程序设计时就得考虑进去，什么信息可以输出，什么信息不能输出都必须是设计阶段就定好的。除非真的有非常特殊的理由，否则任何试图在设计阶段忽略log的行为我认为都是不合格的体现。

重复：printf != log