日常开发中我们经常使用console.log的输出来辅助查看我们所控制的变量的值，有些时候能够正常，而有些时候的输出却在我们的意料之外，到底是什么原因呢？
JS中对象是引用类型，每次使用对象时，都只是使用了对象在堆中的引用。而当我们不展开对象看的时候，console.log打印的是对象当时的快照，所以我们看到的对象的属性值并没有改变，展开对象时，它其实是重新去内存中读取对象的属性值，所以当我们展开对象后看到的属性值与未展开之前是不一样的。
在某些条件下，某些浏览器的console.log(..) 并不会把传入的内容立即输出。出现这种情况的主要原因是，在许多程序（不只是JavaScript）中，I/O 是非常低速的阻塞部分。所以，（从页面/UI 的角度来说）浏览器在后台异步处理控制台I/O 能够提高性能，这时用户甚至可能根本意识不到其发生。
我们通常认为恰好在执行到console.log(..) 语句的时候会看到a 对象的快照，打印出类似于{ index: 1 } 这样的内容，然后在下一条语句a.index++ 执行时将其修改，这句的执行会严格在a 的输出之后。
多数情况下，前述代码在开发者工具的控制台中输出的对象表示与期望是一致的。但是，这段代码运行的时候，浏览器可能会认为需要把控制台I/O 延迟到后台，在这种情况下，等到浏览器控制台输出对象内容时，a.index++ 可能已经执行，因此会显示{ index: 2 }。
到底什么时候控制台I/O 会延迟，甚至是否能够被观察到，这都是游移不定的。
所以如果在调试的过程中遇到对象在console.log(..) 语句之后被修改，可你却看到了意料之外的结果，要意识到这可能是这种I/O 的异步化造成的。
因此，console.log打印出来的内容并不是一定百分百可信的内容。一般对于基本类型number、string、boolean、null、undefined的输出是可信的。但对于Object等引用类型来说，则就会出现上述异常打印输出。
所以对于一般基本类型的调试，调试时使用console.log来输出内容时，不会存在坑。但调试对象时，最好还是使用打断点(debugger)这样的方式来调试更好。
