Debug 在开发调试中，就犹如医生的听诊器，核磁共振... 那，如果设备要是出差错就会误诊，Debug要是出了状况程序也就调不通咯~
下面笔者就讲讲在为这篇文章准备素材案例的时候遇到的关于Debug 的问题吧.

问题代码：

  public float factor = 1;
    float progress = 0;
    bool addition = true;
    void Update()
    {
        progress += (addition ? 1 : -1) * Time.deltaTime * factor;
        progress = Mathf.Clamp01(progress);
        addition = progress == 1 ? false : progress == 0 ? true : addition;
        Debug.Log("Progress: "+ progress + "  progress == 1 ：" + (progress == 1).ToString() + "  progress == 0 : " + (progress == 0).ToString() + " addition : " + addition);
    }

发现问题：

上面一段代码中 Debug.Log 处在一个非常美妙的位置，它负责输出 Progress（进度）的值，但是笔者发现这个 Progress 很难输出0，或者1：

Addition发生翻转变为 True 却无法输出 0 值
Addition发生翻转变为 false 却无法输出 1 值

分析：

这很奇怪：

• 首先，我使用了 Mathf.Clamp01(value) API ,按照预期，当执行到 Debug.Log 肯定有一时刻会输出0和1，但却没有输出。
• 其次 addition = progress == 1 ? false : progress == 0 ? true : addition; 被正常执行，就说明此时 progress 确实是等于1或着 0 的。
• 可是 Debug.Log() 中的progress == 1和progress == 0这两个断言却没一个准确。

OK，简单的追了下源码，想了下还是用玄学来解释好了：
可能 Log数据捕获到给编辑器渲染的过程中有一定几率丢失数据。

那我们怎么确诊（确定）这个Progress的1或者0 一定是输出了，Debug不出来只是 Debug.Log 在搞鬼？
也很简单，就是给 Debug.Log 约束一个条件：

  if (progress == 1 || progress == 0)
 {
      Debug.Log( balabala 等各种断言);
 }

于是，我们得到了下面的效果：

这才是我们想要的啊，久违了！

这才是我想要的输出啊，真的是这个Debug.Log 在搞鬼，弄丢了我的数据，搞得我以为逻辑写错了。

结论及出坑建议：

Debug.Log 在高频度捕获数据时，会有数据不被展示，所以在Debug 在调试高频度输出的数据时最好不要无差别的 Log 它，多多少少给这些值，给这个Debug 约束一个范围。这样也更容易定位到问题…