浏览器里面都有哪些方式可以追踪代码？

哈鲁！今天聊一下浏览器里面有哪些方法可以帮助我们追踪自己的代码。当然，你可能会说，通过console.log啦，通过浏览器打断点啦。这些都没有错，但是还不够，你可能需要更多。

debugger

你可以在代码中加入debugger命令符（姑且认为它就是一个命令符），那么当你通过F12打开devtools之后，当代码执行到该语句时，就会停止执行，出现类似手动打断点的效果，从而你可以在调试界面读取上下文变量的信息。当你再按F12回到正常阅读模式，这种阻断效果就会消失。这一特性，让我们可以把debugger发布到正式环境。（我还看到过通过在死循环中加入debugger语句来避免读者通过F12打开开发者面板查看源代码的骚操作。）

console.trace

除了console.log之外，你最好还掌握console.dir, console.trace这些工具。其中console.trace不仅能打印出信息，还能打印出代码位置栈，从而可以帮助我们快速找到这个信息是由怎样的调用顺序产生的，进而摸索出问题发生的过程。

Error.stack

console.trace可以帮我们打印出位置栈，但是却是一次性使用的，无法在内存中保存起来，我们通过Error的stack则可以拿到这个信息，并保存起来，甚至上报到监控系统。

const { stack } = new Error()

stack是一个字符串，因此，你还可以对字符串进行加工，把不需要的信息剔除掉等等。在我写的小工具 [stupid-vuex](https://github.com/tangshuang/stupid-vuex) 中就利用了这个特性，可以识别到状态变化的位置。

DevTools

此处我的意思是我们可以自己写一个chrome的插件，然后在devtools中增加自己的开发工具。当然，这需要费些功夫，不过在你的项目中或许非常有用。如果你用过redux-devtool, vuex-devtool之类的工具，或许对这个想法非常熟悉。其实创建一个自己的chrome插件也非常容易，无非就是了解chrome的插件api，然后一顿猛如虎的api调用。没错，我们都是可爱的面向api工程师，不是吗？

ChromeDriver

这个方案本质和devtools好像也没有啥差别，只是实现方案和路径不同。通过C/S的架构，我们创建一个后台，然后通过这个后台服务去接管一个由特定参数启动的chrome实例，这样就可以在chrome的渲染界面中将需要的消息发送到服务端，从而更加隐蔽的完成某些数据收集工作。特别是在调试测试阶段，这种方案非常常见，一些集成测试工具，都依赖这项方案，实现一些web自动化集成测试的能力。

好啦！今天就写这么多。