小程序日志分析实战：从混乱到清晰

上线三个月的小程序，用户反馈「偶尔白屏」「支付后没反应」，你打开开发者工具复现十次都正常。这种时候，能救命的只有日志。但很多独立开发者的小程序，日志基本等于没有——要么只在 catch 里 console.log 一句，要么全量上报把后端存储撑爆。这篇聊聊我这两年在小程序日志上踩过的坑和最后沉淀下来的做法。

先想清楚：日志不是给开发看的

刚做小程序那会儿，我把日志当调试输出用，想打什么打什么。后来发现线上问题根本没法查：用户手机在你手里吗？没有。所以日志的第一原则是为「未来的自己」和「客服」服务，不是为当下的 console。

我的划分方式很简单，按用途分三类：

• 错误日志：JS 异常、接口失败、白屏、页面栈异常。必须上报，带堆栈。
• 行为日志：关键路径的埋点，比如进入下单页、点击支付、支付回调。用于还原用户操作链路。
• 性能日志：页面加载耗时、首屏渲染、接口 RT。用于发现慢在哪。

三类日志的采样策略完全不同。错误日志全量，行为日志按需，性能日志可以采样 10%~20%。混在一起上报，后端第一个月就会来找你。

小程序日志的几个特殊坑

1. 日志可能丢在本地缓存里

很多人用 wx.setStorageSync 攒日志，等攒够一批再上报。问题在于小程序被系统回收、用户杀掉进程时，缓存里的日志就永远丢了。我的做法是内存队列 + 定时 flush，队列超过 20 条或间隔 10 秒就发一次，不在本地落盘。

const queue = [];
let timer = null;

function push(log) {
  queue.push({ ...log, ts: Date.now() });
  if (queue.length >= 20) flush();
  else if (!timer) timer = setTimeout(flush, 10000);
}

function flush() {
  if (!queue.length) return;
  const batch = queue.splice(0, queue.length);
  clearTimeout(timer);
  timer = null;
  wx.request({
    url: 'https://api.example.com/log',
    method: 'POST',
    data: { batch },
    fail: () => queue.unshift(...batch) // 失败放回，下次再试
  });
}

2. 上报接口本身也会失败

日志上报最忌讳「上报失败还递归上报」。上面代码里 fail 时把 batch 放回队列，但要加个上限，比如队列超过 200 条就丢弃最老的，否则弱网下内存会一直涨。

3. 别在 onError 里做重活

App.onError 能拿到未捕获异常，但这时候页面状态可能已经坏了。回调里只做一件事：把错误信息塞进队列，其他什么都别干。我见过在 onError 里调接口、读缓存的，结果二次报错，日志全乱。

怎么从日志里定位问题

日志收上来只是第一步，关键是能串起来。我的做法是给每个用户会话生成一个 sessionId，存在全局，所有日志都带上它，同时带上页面路径和用户 openid 的哈希。这样在后台按 sessionId 一筛，就能看到这个用户从进页面到出错的完整时间线。

举个真实例子：用户反馈支付后没反应。日志里看到「点击支付」→「调起支付成功」→「支付回调 success」→ 然后没有「订单页跳转」。问题就锁定在回调后的跳转逻辑，最后发现是 wx.navigateTo 的页面栈超了 10 层。没有行为日志，这个问题能查一整天。

日志的价值不在于「记录了什么」，而在于「出问题时能不能三分钟内还原现场」。

小团队的低成本方案

不想自建日志服务的话，我的建议是：错误日志直接接微信官方的实时日志（wx.getRealtimeLogManager），免费且能在后台看；行为日志用云开发的数据库，写个云函数接收，量小的时候够用。等日活过万再考虑自建或上第三方。

最后提醒一句：日志里别打手机号、身份证、完整 openid。我见过把用户信息明文打进日志的，合规审查直接过不了。打哈希或者只打后四位，够定位就行。