北京小程序调试：真机联调踩坑记

上周帮一位北京做本地生活的客户排查小程序问题，后台数据显示一切正常，但用户反馈「下单后页面卡住」。这种问题在开发者工具里复现不了，只能上真机。今天就把这次调试的过程拆开讲讲，顺便聊聊在北京做小程序开发时，调试环节那些容易忽略的细节。

开发者工具是模拟，不是真相

很多刚入行的朋友习惯在微信开发者工具里点到底，觉得没问题就提审。工具确实好用，但它跑在 Chromium 内核上，和真机的 JS 引擎、渲染层、网络环境都有差异。尤其是下面这几类问题，工具里基本看不出来：

• iOS 上软键盘弹起导致的页面布局跳动
• 低端安卓机的长列表滚动卡顿
• 弱网下的请求超时与重试逻辑
• 分包加载在真机上的实际耗时

我的习惯是：功能逻辑在工具里写，但每个页面至少在一台 iOS 和一台安卓真机上过一遍，别省这一步。

真机调试的正确打开方式

微信开发者工具右上角有「真机调试」入口，扫码后手机会和工具建立连接。这里有个细节：真机调试分「真机调试 1.0」和「真机调试 2.0」，2.0 走的是远程调试协议，能在电脑上看到手机端的 Console 和 Network，排查接口问题很方便。但 2.0 对网络稳定性要求高，办公室 Wi-Fi 抖动的时候容易断连，我一般会切到手机热点再试。

另外，vConsole 依然是兜底利器。在 app.js 里按环境注入：

if (wx.getAccountInfoSync().miniProgram.envVersion !== 'release') {
  const vConsole = require('./utils/vconsole.min.js')
  new vConsole()
}

这样体验版和开发版都能在手机上直接看日志，客户自己点开也能截图发过来，省去不少来回沟通。

一个北京客户的真实案例

去年冬天接了个北京朝阳的餐饮小程序，客户门店在写字楼密集区，中午高峰并发下单。测试阶段一切正常，上线首周却收到反馈：部分安卓用户点「提交订单」后按钮一直转圈。查了半天，问题出在请求超时设置上——默认 60 秒太长，弱网下用户以为卡死就反复点击，结果重复下单。后来改成 10 秒超时加按钮防抖，并给失败请求加了本地队列重试，问题才压下去。

这类问题在工具里永远测不出来，因为工具的网络是「理想网络」。所以我现在给北京客户做小程序定制开发时，会在体验版阶段专门找几位不同机型的朋友帮忙点一遍，尤其是地铁通勤场景——北京地铁的信号大家都懂，那才是真实的弱网环境。

性能面板别只看分数

开发者工具里的「性能」面板能跑评分，但分数高低不代表用户体验。我更关注两个指标：首屏渲染时间和 setData 的数据量。前者决定用户等多久，后者决定页面卡不卡。setData 每次传输的数据建议控制在几十 KB 以内，长列表用分页或者虚拟列表，别一次性全塞进去。

调试的本质不是找 bug，而是还原用户真实的使用场景。坐在工位上永远还原不了。

上线前的检查清单

结合这几年在北京做小程序和 APP 定制的经验，提审前我固定会过一遍：

1. 关闭所有 console.log 和调试开关
2. 确认 request 合法域名已配置，且没有走测试环境地址
3. 真机验证分享、支付、授权登录三条主链路
4. 检查分包体积，主包尽量压在 1.5MB 以内
5. 体验版发给至少两位非技术同事试用

知码客一直信「知码识途、匠心铸客」，调试这活儿没什么捷径，就是把每个环节老老实实走一遍。北京的市场节奏快，客户等不起反复返工，前期多花两小时真机联调，比上线后半夜被电话叫醒强得多。