前言你是否经常碰到业务反馈，线上的小程序某个页面打不开了，订单没法结算了，但是你当时测试的时候都是好好的。 由于线上环境复杂，一些问题只会在特定网络环境或者设备上发生，对于这类问题，异常信息的收集就显得格外重要了，我们不但希望收集错误的堆栈信息，还需要用户操作流程，设备信息等，以便复现错误。 简单收集小程序App()生命周期里提供了onError函数，可以通过在onError里收集异常信息 App({  // 监听错误  onError: function (err) {    // 上报错误    wx.request({      url: "https://url", // 自行定义报告服务器      method: "POST",      errMsg: err    })  } }) 用户操作路径收集一些较隐蔽的错误如果只有错误栈信息，排查起来会比较难，如果有用户操作的路径，在排查时就方便多了。 方法一：暴力打点方法收集 优点：简单直接 缺点：污染业务代码，造成较多垃圾代码 方法二：函数劫持（推荐使用） 需要在App函数中的onLaunch、onShow、onHide生命周期插入监控代码，我们通过重写App生命周期函数来实现。 App = function(app) {    ["onLaunch", "onShow", "onHide"].forEach(methodName => {        app[methodName] = function(options) {          // 构造访问日志对象          var breadcrumb = {            type: "function",            time: utils.now(),            belong: "App", // 来源            method: methodName,            path: options && options.path, // 页面路径            query: options && options.query, // 页面参数            scene: options && options.scene // 场景编号          };          self.pushToBreadcrumb(breadcrumb); // 把执行对象加入到面包屑中    }) }但是这样写，会把用户自定义的内容给覆盖掉，所以我们还需要把用户定义的函数和监控代码合并。 var originApp = App // 保存原对象 App = function(app) {   // .... 此处省略监控代码   // .... 此处省略监控代码   originApp(app) // 执行用户定义的方法 }记录结果 可以从下面的json看出，用户到了detail页面，执行了onLoad => getDetail => onReady => buy 当执行buy方法的时候报错。 [{"method":"onLoad","route":"pages/film/detail","options":{"id":"4206"}}, {"method":"getDetail","route":"pages/film/detail","options":{"id":"4206"}}, {"method":"onReady","route":"pages/film/detail","options":{"id":"4206"}},{"method":"buy","route":"pages/film/detail","options":{"id":"4206"}}] 上报策略考虑到在大型应用中，日志量比较大，我们采取抽样，合并，过滤三个方法减少日志的输出，代码实现可以参考lib/report.js 代码组织项目使用rollup作为构建工作，实现ES6转ES5，模块加载功能。 项目目录如下： config.js  // 配置文件 core.js // 劫持小程序核心代码 events.js  // 监听自定义事件 report.js // 上报类 utils.js // 工具类 🌟喜欢的点个star：https://github.com/zhengguorong/xbossdebug-wechat

对于小程序开发者来说，其中的错误监控一直是个头疼的问题。由于小程序开发迭代较快，会存在系统问题，机型问题和版本的兼容问题，有时候我们在自行测试中完美运行，可总是有用户抱怨使用异常。如果我们对小程序的错误进行有效的监控，可以帮助小程序开发者发现异常，优化代码，用户体验也会随着优化逐步的提升。 作为一个小程序开发者，如果你对前端开发比较熟悉，那么在错误监控方面可能会更快的上手。因为小程序错误监控和 Web 端错误监控本身就具有很多相似性，因此监控的数据规则基本是一致的，但由于小程序自身的特性，在错误监控方面会有以下不同： 在 Web 端我们监测的是页面完整的 url，而小程序端监测的是路由地址； 小程序页面属于微信内部的页面，使用时已全部加载完毕，因此监控页面性能时不统计页面加载时长等信息，更多的是对页面内请求、资源请求和用户行为的监控； 由于微信官方和小程序代码的要求，集成方式对比 Web 端会相对严格一些。 根据以上的相同点和不同点，我们可以整理出对于小程序而言，哪些数据是需要监控的： JavaScript异常监控：不论是 Web 端还是小程序端，对 JavaScript 异常的监控都是必要的； 页面内请求监控：对于小程序来说，我们需要统计发送网络请求的 wx.request() 异常时的请求状态、请求时长、请求地址等； 资源加载监控：当需要下载资源到本地的 wx.downloadFile() 出现异常时，统计加载时间、异常类型、资源地址等； 页面性能监控：访问监控、页面来源及流向监控等，方便我们更好的对小程序进行运营； 用户数据统计：用户的分布、操作系统及版本、微信版本、IP 地址等，给错误的分析提供更多条件。 对于小程序出现的错误，我们目前只能在开发者工具上进行追踪和调试，有条件的开发者也可以选择在真机上进行调试，但是小程序大多还是小团队和个人开发者，拥有不同操作系统，不同型号，不同版本的真机进行调试还是不太现实，这里就可能会出现在本地调试中没有出现的问题，且很难定位的到。 在目前的微信小程序后台中，对于上面第4和第5点的监控和统计已经可以实现，用户数据的分析也比较完善，但是对于错误的监控目前还无法实现，这里我们可以借助第三方工具来进行对错误的监控。 这里我们选择错误监控平台FrontJS的小程序错误监控：https://www.frontjs.com/  FrontJS的小程序错误监控相比于微信小程序后台的数据监控，增加了对于错误的统计和产生错误的相关用户分析，FrontJS可以收集精细到 console.log 级别的任何 JavaScript 异常信息并提供 stack trace 信息；对于任何一条错误信息或访问，它都会统计到该用户IP、屏幕分辨率、DPR、操作系统类型和微信版本，方便我们更有针对性的去调试出现的错误。 使用时我们只需引入FrontJS插件，并添加配置代码，即可开启监控。 具体方法： 进入FrontJS后注册账号，登陆后选择创建项目，在创建项目页面的名称后选择“微信小程序”。  [图片] 在这个页面也可以对不监听的资源和信任域进行设置。  [图片] 创建完成后，我们只需要根据页面右侧的提示进行操作，就可以完成小程序错误监控的全部设置。集成完毕后就可以开始错误的监控了，具体界面如下，在左侧菜单栏中我们可以选择不同的条件进行错误的筛选，具体内容各位可以亲自尝试。  [图片] FrontJS对微信小程序下已有的相关方法进行了监听，在出现异常或需要监控时，FrontJS会及时发现并统计数据，并且完全不影响小程序的正常运行。 在后续更新中，FrontJS 会继续挖掘可监控到的信息，如用户的位置信息，语言，基础库版本等，对这些信息做更优处理，配合可视化工具，开发者将可以构建出更符合自身需求的数据方案。

picker 地区选择器，广东省深圳市没有光明区，都一年了，数据还没更新，严重影响小程序业务开展。