小程序业务的蓬勃发展，离不开第三方服务商的支持。平台希望第三方服务商明确自身的责任担当，和平台建立良好的信息通路，实现最终的合作共赢目标，从而推出了一系列以审核为基础的运营机制优化方案。 一、预检机制（上线时间：8月15日） 为了综合提升第三方审核效率，平台将于8月15日起，推行小程序第三方预检加速机制。针对第三方短期内大批量提审的小程序，平台将随机抽取一批提审小程序作为样本进行预先检查，其中对于预检质量较为优质的第三方，将会安排加速审核（审核时长<12小时）；对于预检质量较为低劣的第三方，将会安排审核降级（即延期3-7天后进行审核）。后续提审质量较为优质的第三方，将会实现更快过审。 [图片] Q：这批小程序被延迟审核了，服务商怎么收到通知的？ A：每天中午12点，若存在还未审核或撤回的延期审核小程序，平台会通过服务商站内信定期通知，此外，当一个小程序进入延迟审核状态时，会通过推送接口（点击查看）进行推送。第三方也可以使用查看接口（点击查看），查询某个小程序是否在延迟审核状态。 Q：怎么撤回延迟审核状态的小程序？ A：第三方可以通过撤回接口（点击查看）撤回延迟审核中的小程序，按照站内信反馈的违规原因分布，进行优化后再次提审，以提升审核效率。 Q：撤回后提审会消耗我每月的quota么？撤回后提审还不通过怎么办？ A：每次撤回再提审都会消耗当月的quota值，第三方的提审合格率会是后续审核资源分配的重要评估维度。撤回后不优化再次提审，会导致本月提审合格率下降，影响后续的资源分配！ Q：预检的准确性如何，样本不合格，总体也有可能是合格的呀？ A：平台会不断对比样本和总体的准确率，完善预检模型，确保预检的科学合理性。从之前灰度的情况看，预检的科学性有很好的保证，样本的合格率可以准确反馈总体的合格率情况。 Q：预检质量好和坏怎么决定？为什么我整体合格率还可以但还是没有过预检？ A：预检质量当前包括以下两个维度：1，整体合格率（合格小程序/样本总数），2，高危违规比例（高危违规个数/样本总数），其中，高危违规定义为：涉及黄赌毒等平台不允许的内容，金融、医疗、社交等风险高的类目，以及其他平台评估对小程序生态、用户体验危害大的行为。 二、提审额度限制（quota）（上线时间：9月1日） 由于第三方业务的快速发展，每日审核的单量逐步增多，部分第三方提审习惯差，大量无效低质的提审，阻塞了审核队列，需要对这批第三方进行提审限制，保证其他第三方的提审体验。 每个第三方后续的提审，将按月分配一定的额度，当每月提审次数超过提审额度时，将无法继续提审，需要等待下月1号重新分配额度。提审额度的分配和调整，将基于第三方的业务发展需要、提审质量、线上小程序违规情况等因素进行综合考虑。 三、加急审核（上线时间：9月1日） 为了保证第三方的重要核心业务不受审核排队影响，提升第三方提审体验，平台计划9月上线加急审核功能，对第三方开放一定的加急额度。加急小程序保证小于12小时的审核时效。 第三方加急审核适用的小程序： 1，授权给该第三方且满足一定期限 2，当前在审核排队队列中 3，无其他平台不允许加急因素存在 四、第三方反馈和运营控制（下半年上线） 为了加强第三方和平台的相互理解、信息互通，避免在实际运营过程中，因为信息不通导致的低效问题，后续平台将加强和第三方的线上线下交流，同时完善各个环节的信息沟通反馈机制。同时，对于第三方，将采用更多的措施进行运营，对于表现好的第三方，后续将在各个环节给到相应的支持，对于表现不好的第三方，将给到相应的处罚，表现特别恶劣的第三方，后续将清除出平台。 更多信息请关注后续上线公告

前言你是否经常碰到业务反馈，线上的小程序某个页面打不开了，订单没法结算了，但是你当时测试的时候都是好好的。 由于线上环境复杂，一些问题只会在特定网络环境或者设备上发生，对于这类问题，异常信息的收集就显得格外重要了，我们不但希望收集错误的堆栈信息，还需要用户操作流程，设备信息等，以便复现错误。 简单收集小程序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