上线只是开始

很多团队把小程序提审通过当成终点，其实那只是起点。线上真实用户的手机、网络、机型千奇百怪，开发机上测不出来的问题，一上线就冒出来。没有监控，这些问题只能等用户投诉才知道，那时候已经晚了。

线上治理的核心，是把「用户在踩坑」变成「我们先发现」。监控、采集、告警、闭环，四件事串起来。

监控这事要趁早做。项目小的时候加上去不费劲，等做大了再回头补埋点和采集，成本高得多。

没监控的线上，等于闭着眼开车。
本文核心知识点
  • 性能监控启动、渲染、接口耗时看住。
  • 错误采集前端报错和接口失败都报上来。
  • 告警问题到阈值就叫人，别靠刷面板。
  • 闭环发现、定位、修复、回归走通。
小程序性能监控示意：蓝调渐变背景上仪表盘波形曲线与告警节点的扁平科技插画
把性能和错误都收进同一块面板，线上才真正看得住。

监控什么：性能与错误

小程序要盯的指标其实就两类：体验类和错误类。体验类看启动耗时、首屏渲染、页面切换、接口耗时；错误类看 JS 报错、接口失败、白屏。

指标说明
启动耗时冷启动到可交互
接口成功率失败比例突然上升要警觉
JS 错误数新版本上线后是否飙升

别贪多。先把这几个核心指标看住，比一上来堆二十个指标、谁都不看强。

这些指标最好能按版本、按机型拆开看。同一个报错，可能只是某一款旧机型上才有，不拆开根本看不出来。

接口耗时要看慢请求。平均耗时好看，不代表慢请求不多，把长尾分位也看一眼，用户体感往往卡在长尾上。

错误采集与上报

小程序有全局错误监听，未捕获的异常在这里能兜住。接口失败也单独上报。上报时带上机型、版本、页面路径，否则报错来了也不知道是哪台机器、哪个页面。

wx.onError(function (err) {
  report({ type: "js-error", msg: err, page: getCurrentPage() });
});

上报别太密。同一种错误短时间内去重合并，不然一次线上 bug 就把上报额度打满。

除了主动上报，还要注意别把用户隐私信息打进日志。手机号、证件号这些绝不能跟着报错一起传上来，那是另一类合规风险。

告警与值班

光有面板没用，没人盯着。设告警：接口成功率跌破阈值、JS 错误数环比翻几倍，就推到群里。

  • 告警要分级，重要的才叫人。
  • 别什么都报，噪声多了真报警也会被忽略。
  • 值班表里留好联系方式。

告警还要配好值班轮换。别指望一个人全年无休盯着，休假了没人接班，告警等于白设。

告警渠道也分个级：致命的直接电话或短信，一般的发群里就行。别让所有人对所有告警都一样紧张。

真出大事的时候，别只盯着数据面板，用户反馈渠道也要一起看，有时候用户说的问题面板上还没反映出来。

线上治理闭环

发现问题只是第一步。真正值钱的是闭环：发现、定位、修复、再验证。每个线上问题最后都要有个收尾，不能修完就忘。

// 上报时带上版本号，方便按版本看问题
report({ type: "api-fail", ver: appVersion, path: apiPath });

尤其关注「新版本上线后」的曲线。新版本是最容易出问题的时候，盯紧它。

每次修复完问题，回头看看是不是同类问题反复出现。反复出现的，说明根子上没解决，得从流程或架构上动手，而不是每次打补丁。