拿到一个报错，第一反应不是去查文档，而是打开控制台看那一行红字。我见过太多新手卡在这一步，对着屏幕干瞪眼，其实微信开发者工具已经把答案怼到你脸上了。调试这活儿，说白了就是跟代码对话，你得先学会听它说什么。

先说说最基础也最容易被忽略的：Console面板。很多人以为它就是打印日志用的，其实远不止。除了常见的console.log，你试过console.warn和console.error吗？Warn会显示黄色警告，Error是红色报错，一眼就能分清轻重缓急。更妙的是，你可以直接在这个面板里敲代码——比如临时改个变量的值，看看页面反应，不用动源码，改完刷新就还原，这对排查那种“改一下就没问题，改回去又出bug”的玄学问题特别管用。还有个小技巧，用console.table输出数组或对象，结构一目了然，比一长串log清爽太多。我调试列表数据时几乎离不开这个，字段名对不对，有没有undefined，扫一眼就明白。

Network面板是另一个重头戏。小程序请求接口出问题，十有八九是这里能看出端倪。打开它，发个请求，你会看到每个请求的耗时、状态码、返回体。状态码200不代表数据没问题，你得点开看Response里的实际内容——有时候后端返回的是个错误提示，但HTTP状态码却是200，这时候只看状态码就被坑了。还有个小细节，请求头里的User-Agent会标明你是从微信开发者工具发的，还是真机发的，有时候同一个接口，两种环境请求头不一样，后端处理逻辑也不同，这就能解释为什么工具里好好的，真机一跑就挂。另外，Network面板里的耗时分布图特别有用，DNS解析、建立连接、发送请求、等待响应、下载数据，哪一步慢了，一眼就看出来，优化性能就靠它定位。

真正进阶的调试，得学会用Sources面板打断点。很多人只会console.log，打完删，删完再打，效率低不说，还容易漏。打断点就不一样了——你在某一行代码左侧点一下，出现蓝色标记，然后触发这个函数，执行到这一行就会暂停。这时候你可以看右侧的Scope区域，所有局部变量、全局变量的当前值全摊开，还能在Watch区域手动加你要盯的表达式。鼠标悬停在变量上也能看到值，但复杂对象就得用Watch。更厉害的是，你可以直接在调试状态下修改变量的值，然后继续执行，看看后续逻辑会不会变——这比改代码刷新快多了，特别适合排查那种“这个值明明不对，但不知道什么时候被改的”问题。还有条件断点，右键断点标记，输入一个表达式，只有当这个表达式为true时才暂停，比如i > 5，循环到第六次才停，省得你一次次按继续。

AppData面板是微信开发者工具独有的宝贝，别的IDE可没有。它显示的是整个小程序当前的数据状态，所有页面的data都在这。你可以直接展开、修改里面的数据，页面会实时更新。这功能强在哪？强在你不用触发任何事件，就能模拟任何数据状态。比如你有个页面，要展示一个空列表、一个加载中的状态、一个加载失败的状态，正常你得写一堆假数据去触发，但有了AppData，直接改data里的数组长度，或者把某个字段改成null，页面立刻变样。调试那种“数据一多就布局错乱”的问题，直接在AppData里把数组撑到几十条，马上就能复现。还有个隐藏用法——对比数据。如果你怀疑某个操作改了不该改的数据，操作前先在AppData里看一眼原始值，操作后再看，多出来的、少掉的一目了然。

真机调试是绕不开的一关。很多问题在开发者工具里完美运行，一到真机就露馅——比如某些API在工具里是模拟的，真机上才有真实行为；还有性能问题，工具里跑得飞快，真机上卡成PPT。点击工具栏的“真机调试”按钮，用微信扫码，手机上就能看到实时日志和页面状态。但注意，真机调试和直接预览（就是那个“预览”按钮）有区别——预览是完整跑一个独立小程序，真机调试是连着开发者工具的，能看到日志和网络请求，但性能会比正式版略差。真正要测性能，得用“性能面板”或者直接预览后看微信里的“体验评分”。我建议，但凡涉及定位、蓝牙、支付这些硬件或系统能力的功能，必须真机调试，别偷懒。

存储和缓存的问题，很多人栽过跟头。小程序有同步和异步两种存储API，sync结尾的是同步，不带的是异步。同步的会阻塞线程，数据量大了容易卡，但调试时反而方便——因为代码顺序执行，你能确定哪一步写入了什么。异步的不阻塞，但回调时机不好把握。排查存储问题，我有个土办法：在AppData旁边的Storage面板里直接看当前所有缓存数据。这面板能显示所有key和value，还能手动删除或修改。有时候你怀疑某个缓存没清干净，直接在这里删掉，然后重新触发逻辑，看看会不会重新写入。另外，注意存储的容量限制——单个key最大1MB，总容量10MB，超了会静默失败，不报错，但数据就是写不进去。这种坑，不看Storage面板根本发现不了。

WXML的调试经常被忽略，但它其实藏了不少坑。比如你渲染一个数组，但数据里有个字段是undefined，页面不会报错，只会渲染成空白。这种问题Console里也看不到报错，只能靠WXML面板排查。开发者工具左侧的WXML面板会显示当前页面的节点树，你把鼠标移到某个节点上，页面上对应的元素会高亮，反过来也一样。更实用的是，你能看到每个节点的绑定数据——比如一个text节点，它会显示当前渲染的文本内容，你一眼就能看出是不是undefined。还有事件绑定，面板里能看到这个节点绑定了哪些事件，如果事件没触发，先看看是不是绑定错了。这个面板还有个妙用：检查样式。选中一个节点，右侧会显示它的所有CSS属性，以及哪些是继承的，哪些是覆盖的，排查样式打架的问题特别好使。

说点排查思路层面的东西。遇到bug，别急着改代码，先复现，再定位，再修复。复现的时候，注意看是必现还是偶发——必现的问题大概率是逻辑漏洞，偶发的问题可能跟时序、网络、状态有关。定位的时候，二分法最有效：在关键路径上打日志，看数据流到哪一步断的，然后把搜索范围缩小一半。我见过有些人一上来就怀疑框架bug，其实99%的问题都是自己代码的边界情况没处理好。调试工具是死的，思路是活的。养成一个习惯：每次修复完，别急着关调试器，多跑几遍触发路径，确认没有副作用。小程序迭代快，但调试这事儿，稳扎稳打永远比花里胡哨强。你把上面这些工具都摸透了，遇到报错就不再是两眼一抹黑，而是能顺着线索一路追到根因——这才是从入门到精通的真正分水岭。