小程序调试那些坑，我踩了三年才明白

做小程序这几年，我越来越觉得调试这件事被低估了。很多人以为写完代码点一下编译，模拟器上跑通了就完事，结果一上真机全是问题。今天就把我踩过的坑和总结出来的调试套路写一写，都是实战里磨出来的。

别把模拟器当回事

微信开发者工具的模拟器确实方便，但它和真机差距比你想的大。最典型的就是网络环境、设备性能和系统 API 的差异。我遇到过一个很离谱的 bug：模拟器上列表滚动丝滑，真机（某台老安卓）上直接卡成 PPT。后来查出来是 scroll-view 里嵌了太多复杂节点，加上图片没做懒加载。

所以我的习惯是：模拟器只用来验证逻辑和样式，交互和性能一律上真机。开发者工具右上角那个「预览」和「真机调试」按钮，用得比「编译」还勤。

真机调试的两种姿势

• 预览：扫码在手机上跑，适合快速看效果，但不方便看日志。
• 真机调试：手机和电脑连上，控制台日志、网络请求、Storage 都能实时看，排查问题首选。

真机调试有个小坑：手机和电脑必须在同一网络下，公司网络有隔离的话就连不上，我一般直接开手机热点。另外调试时手机会弹一个调试面板，别嫌它碍事，那个面板能看当前页面的 data，比在电脑上猜强多了。

Console 之外，学会用 AppData 和 Network

新手最容易忽略开发者工具里的两个面板。

AppData 面板

它能实时显示当前页面的 data，还能直接改值。调试表单联动、条件渲染的时候，改个值看视图怎么变，比反复改代码重新编译快十倍。

Network 面板

接口报错别只看 console.log，Network 里能看到请求头、响应体、状态码，连耗时都有。有一次线上接口偶发失败，就是靠 Network 发现请求被重定向了，问题出在域名配置上。

// 调试请求时，我习惯包一层，方便在 Network 里认出来
function request(url, options = {}) {
  console.log('[REQ]', url, options.data);
  return wx.request({
    url,
    ...options,
    success(res) {
      console.log('[RES]', url, res.statusCode, res.data);
      options.success && options.success(res);
    },
    fail(err) {
      console.error('[ERR]', url, err);
      options.fail && options.fail(err);
    }
  });
}

那些只有真机才暴露的问题

• 授权弹窗：模拟器上点一下就行，真机上用户拒绝后要引导去设置页，逻辑得写全。
• 键盘遮挡：输入框在页面底部时，真机键盘弹起来会挡住，要配合 adjust-position 或手动滚动。
• 分享和场景值：从群聊、朋友圈、扫码进来的场景值不一样，模拟器很难模拟全，得用真机测。
• iOS 和安卓差异：日期解析、new Date('2024-01-01') 在 iOS 上可能返回 Invalid Date，这种坑模拟器根本发现不了。

线上问题怎么查

代码上线后出的问题才是最要命的。我现在的做法是：

1. 接入小程序的实时日志能力，关键路径打点，用户反馈问题时能按时间捞日志。
2. 用 wx.getRealtimeLogManager 记录错误堆栈，比让用户截图强太多。
3. 版本回退要熟练，后台可以指定版本，出大事先回滚再慢慢查。

调试的本质不是找 bug，而是缩短「发现问题」到「定位问题」的距离。工具用得顺，很多问题在发生前就能被看见。

最后说句实在话，调试能力比写代码能力更能体现一个开发者的水平。多上真机、多看日志、多复盘，坑踩多了自然就有肌肉记忆了。