微信小程序调试实战，那些你忽略的坑与技巧

调试小程序这事儿，说大不大，说小不小。刚入行那会儿，我以为调试就是console.log打天下，顶多再点点Sources面板，后来被线上问题折腾得够呛，才发现自己连“看门道”的门都没摸着。微信开发者工具里藏着不少反直觉的坑，可能你天天在用，却从来没意识到它们正在悄悄误导你。

先说说最容易被忽略的“真机调试”和“模拟器调试”的区别。模拟器里跑得顺顺畅畅的代码，一到真机上就卡顿、白屏、请求超时，这种事我遇到不下十回。原因很简单，模拟器的渲染引擎和真机不完全一致，尤其是涉及到canvas、map这类原生组件，还有video的自动播放策略，模拟器上的表现经常是“理想状态”。我习惯的做法是，每改完一个涉及原生组件的功能，立刻用“预览”功能扫码到手机上跑一遍，别等攒了一堆再测，到时候你根本分不清是哪个改动引入了问题。

再聊聊那个几乎人人用错的东西——console.log。很多人以为console.log就是打印个变量值，但小程序里的console有个隐蔽的特性：它打印的是对象的引用，不是快照。什么意思？你console.log一个对象，然后在后面几行代码里修改了这个对象的某个属性，再展开控制台看之前打印的那条日志，你会发现那个属性已经变成修改后的值了。这玩意儿特别坑，排查异步数据问题的时候容易被带偏。我现在的习惯是打印时用JSON.parse(JSON.stringify(obj))做一次深拷贝，或者直接打印特定字段，别偷懒。

另一个经常让人抓狂的坑是“本地存储”的数据类型错乱。Storage里存进去的数字，取出来变成了字符串，或者布尔值变成了字符串“true”。这通常不是小程序本身的问题，而是你在setStorage的时候，数据经过了一层隐式转换。比如从input组件拿到的值，永远是字符串，你直接存了，取出来用的时候忘了转，bug就在不经意间冒出来了。调试这类问题，别光看Storage面板里的值，那上面显示的就是字符串，你得在代码里断点看类型。我习惯在存取的地方封装一层工具函数，强制类型校验，省得每次都得翻半天。

还有网络请求的调试，这里有个不少人不知道的小技巧——利用工具的“Mock”功能，但大多数人把它用歪了。Mock数据是为了在接口未完成时联调前端逻辑，但很多人mock完就忘了关，导致线上环境跑着mock数据，页面看起来正常，实际全是假的。我自己的做法是，在mock数据里加一个明显的标记字段，比如__mock: true，然后在app.js启动时检查环境变量，只有开发环境才允许加载mock，发布到体验版或正式版时就自动剥离。这样既方便调试，又不会捅娄子。

再来说说性能调试。小程序的性能面板里能看到很多指标，但大多数人只看个“运行内存”和“CPU占用率”就完事了。其实那个“渲染层”和“逻辑层”的耗时分布更有价值。如果你发现逻辑层脚本执行时间特别长，那就得考虑是不是有大量的同步计算阻塞了线程，比如循环里做复杂运算，或者频繁调用setData传了大体积数据。有个坑我踩过好多次：setData传的数据里包含了不必要的字段，哪怕这些字段在渲染层根本用不到，也会造成额外的通信开销。调试性能问题时，先把setData的调用点都列出来，逐个检查传的数据结构，往往能省出不少性能。

还有一个隐蔽的坑，跟“分包加载”有关。小程序分包之后，主包和分包之间的跳转和传参，有时候会因为路径写错而静默失败。你点击一个跳转按钮，页面没反应，控制台也没报错，这时候大多数人会怀疑是bindtap没绑上，其实是分包路径漏了前缀。我调试这类问题时，会直接在onLoad里加一个console.log打印options参数，看看是否收到了值，再检查跳转路径是否写全了“/subpackages/xxx”的前缀。别小看这个，线上用户反馈点按钮没反应，十个里有七个是路径问题。

说一个工具本身的坑：开发者工具的“自动热重载”功能，偶尔会抽风，尤其是你同时改了多个文件的时候。有时候你改了js文件，工具没触发重新编译，你还在旧逻辑里调试半天，怎么改都不生效。我现在的习惯是，改完代码习惯性地按一下Ctrl+B手动编译一次，看着编译完成的提示再开始调试。别太信任工具，关键时刻还得自己动手。

调试小程序这事儿，说到底就是个“较真”的活儿。那些看起来玄乎的线上bug，追根溯源，多半藏在上面这些不起眼的细节里。工具给的功能，不是每样都适合你的场景，也不是每样都像文档里说的那么靠谱。趁着项目还没上线，多花点时间把这些坑摸清楚，总比上线后半夜爬起来看告警强。