背景介绍 我司有一款健康记录的微信小程序产品，为了程序的健壮性，前辈开发者们在产品开发初期就引入了[代码]wx.request[代码]响应超时，自动重发的逻辑。本月产品迎来重大迭代，用户量开始增加。sentry中突然有一个错误日志断断续续出现，日志显示前端收到了接口的response，但是response中没有数据。而后端确认接口是有数据的，多么诡异的问题，唯一有迹可循的是，接口报错时，是接口超时没响应后重发的第二次请求 [图片] 开始排查 作为公司唯一的实习生，我荣获了周末加班排查这个bug的殊荣，打开我的大宝剑，错了，打开我的macbook，打开IDE，我发现了前辈们在接口重发逻辑中写的一个我不认识的东西 [代码]this.requestTask.abort() [代码] [图片] 马上打开官方文档查看 [图片] 文档让我心里慌的一比，没办法，只能自己去尝试 [图片] 举个栗子🌰 为了胜利我把重发的核心逻辑剥离出来放在一个单页面的小程序中，大概就是这样👇 [代码] data: { requestTask: null, retryRequest: null, retryCount: 0, timeout: 50 // 为了测试我把接口超时的时间改成了50ms }, test: function() { if(this.retryCount>3) { clearTimeout(this.retryRequest) return false } this.retryRequest = setTimeout(() => { this.retryCount++ this.requestTask.abort() // 中止上一个请求 this.test() // 调用自己发起下一次请求 }, 50) this.requestTask = wx.request({ url: 'api', success: (res) => { console.log('in success:', res) clearTimeout(this.retryRequest) }, fail: (res) => { console.log('in fail:', res) } }) } [代码] RequestTask.abort()分析 来，请大家猜猜下面红色的error是代码错误了还是中断成功了？ [图片] 恭喜，这是请求中止成功啦。鼓掌！！！ abort()函数执行成功(请求被中止)，会进入fail回调和complete回调，如果errMsg == “request:fail abort”，就表示之前的请求被中止了。至于为什么会有红色的报错(没有任何意义)，这是爱的鼓励，不要问为什么。 [图片] 重现问题 我一遍又一遍的点击着小程序开发者工具的编译按钮，发现在我点击十次之内，一定会出现重发多个请求后，有一个请求得到响应，其他请求被取消，而在success中打印res，发现里面的data不见了，就是下面这样👇 [图片] 推测一下 [图片] abort()函数是已经封装好的函数，是一个异步的函数 原先的逻辑中，abort被执行，但是并不知道请求是否已经彻底终止，就发起了下一个请求 [代码]this.requestTask.abort() this.test() [代码] 就在终止请求的时，下一个请求响应，底层开始处理请求的响应，上一次的终止逻辑被停了。最后，上一个来不及终止的请求也得到了响应，各种巧合导致其中一个得到响应的请求，success回调中打印不出来data 改动一下 在定时器setTimeout中执行requestTask.abort()，在fail的回调中，只有判断出res.errMsg === 'request:fail abort’的情况下，表示上一个请求已经彻底终止。重发下一次请求 [代码] test: function() { this.retryRequest = setTimeout(() => { this.requestTask.abort() }, 50) this.requestTask = wx.request({ url: 'api', success: (res) => { console.log(res) clearTimeout(this.retryRequest) }, fail: (res) => { if (res.errMsg === 'request:fail abort') this.test() }, complete: function (res) {}, }) } [代码] 鸣谢 [图片]

[图片] 上周参加了“上海微信开放社区”的沙龙活动，看到现场大家回答问题都很踊跃，回去自己也思考了下，先看下10月24日（1024如此重要的节日发布。。。emmm。。。）官方公布的内容： 《社区突出贡献者激励计划》。 首先有点必须值得肯定，官方正在努力做出改变，并且把平台建设的更好，基于“人人都是产品经理”的思想，我这里也给到一些整理后的建议。 免责申明：由于可以拿到的关键数据有限，作为一个数据控，略感无奈，很多时候做决定或给建议只能通过个人主观认知来判断，但本人会尽力秉承理性和客观来给出一些看法。 1、奖励机制 1.1、“全周期”评价，积分系统 积分是一个累加的概念，它表明你对这个平台付出的总额。个人觉得这个是重要的奖励机制，为什么呢？ 打个比方，现在的奖励机制是按照月度来的，展示的是单月的贡献，那么就会有个问题： A同学：5月份非常积极，为平台贡献了1000，获得月度突出贡献奖，但后面就再没有贡献了，一年贡献总额为1000 B同学：每个月都有贡献，每月100点，坚持了一年，那么总额就是1200 可以看到，其实是B同学对整个平台总体贡献大，但按照现在的机制只有A同学能获得奖励~ 这样或多或少都会打击B同学这类贡献者，他们或许因为工作满或者没有那么多连续的大量时间，平台就忽略他们的贡献~~~ 结论：建立全周期评价体系，加入积分机制、年度，季度贡献者的评选。 1.2、贡献者评价的一些基础数据 用户点赞 用户收藏 评论 浏览次数&分享 投币：类型于B站的投币机制，可以每个月给用户5个币，投完为止，限量才能突出用户选择的谨慎性和投币对象的价值。 投诉：这类反馈要更加谨慎和细致 关于是否需要赞对应的“踩” ？ 回答问题类：一定需要，因为有这种情况，一个回答能解决当前问题，但可能引起“次生灾害”导致其他的问题，但由于先前点赞数过高，一直排名靠前，可能出现误导~ 文章类：不建议有“踩”，因为写文章的成本较高，更多的是提供一个全流程解决方案，而非简单的对错判定，当然也不需要所有人满意~ 结论：这里 每个数据的权重 是最为关键的，官方到时候是否公布，也是要细致考虑，个人认为：投币 = 投诉 > 收藏 > 点赞 = 评论 > 浏览次数 1.3、最终奖励 建立周边商城，利用获得的积分或者虚拟货币兑换各类物品（开放社区都是实名制的，不用担心刷子薅羊毛） 1.3.1、虚拟奖励 特有头像、头环 专属徽章，如“九月社区突出贡献个人开发者” 加快小程序审核时间 发表的文章/回答的问题 能优先被“置顶、推荐、加精”等 云函数、云服务等器免费使用额度 兑换一些腾讯系的虚拟物品 个人小程序开发，给予更大的权限，比如个人小程序可以使用web-view 优先参与“内测”的机会，观看付费教学视频等~ 核心：可以在回答问题和发文章一眼看出此类“专业用户”，要有一定区分度 1.3.2、实物奖励 特色周边，比如企鹅毛绒玩具，手机壳等 徽章、勋章 里程碑奖品：类似B站，10W粉丝会给一个银色奖杯牌，100w会给一个金色的 可以优先参加一些分享会或者现场培训 google的做法，参与互动就有奖励，如图： [图片] 实物奖励核心：一定要突出实用性并且可反复展示，人一定是会有虚荣心的，但这不一定是负面的，而可能成为持续性的鼓励，比如每当你看到桌面上的“奖杯”。。。想起。。。~~~ 结论：专家级用户一定是少数，但他们反而是最重要的，他们提供了正确率和解决问题效率！奖励的核心是让真正的贡献者获得“荣耀感”，建立“忠诚度”，让他们能为建立强大的微信开放社区持续性投入。 2、社区交互和界面优化 2.1、页面交互优化 2.1.1、将“我的关注”修改成“我的” [图片] “我的”我的模块可以加入三个标签： 我的提问（默认第一个显示），根据观察，这个平台上用户更关心自己的问题是否得到解决，围绕“我的问题”是第一需求。 我的关注：保持不变 我的状态/积分：包括评论，点赞等信息，现在是最上面，且单独打开窗口，不太友好，切换起来也不方便~ 建议去掉头部的“全部、文章、问答”这一栏，改成“推荐，我的，疑问/BUG”，将文章和问答加入到筛选Label中。 2.1.2、搜索和筛选排序优化 [图片] 添加其他几个筛选选项，比如点赞数最高的回答，收藏数最高的文章等等 2.1.3、个人提醒小优化 比如这种情况，有十几个未读信息，但是点击进去后，需要一个个点开，才能去掉红色的“未读状态”，逼死强迫症啊~ 建议：点进去，就直接把16个未读状态归零，但是可以在“详情页面”中看到标记~ [图片] 2.1.4 小程序核心 小程序发布文章肯定不方便，个人觉得更多的是简单回答问题和评论，所以小程序端的核心应该是“资讯的接收和BUG修复的提醒”，这里小程序的订阅功能会变得更加强大，比如，某某BUG官方已修复的订阅推送~~~ 2.2、奖励栏优化+ 荣誉墙页面 [图片] 个人贡献者只有10个能入选太少了！！！ 建议增加至20/50个奖励名额，让更多的人可以上榜，一定不会是件坏事，这里可以设置前1-3名特殊的ICON，前4-10名一个标签，首页隐藏其他11-50名，但是有一个荣誉墙页面，里面可以查到以往所有的“优秀贡献者”~~~ 荣誉墙未来可以添加其他排行榜，作为小程序开发者的一种荣耀~ 2.3、BUG的整理、追踪和反馈 从目前看来用户最关心的是： BUG的处理方法和是否解决！！！！！！ 同类问题的归类合并，避免反复提问，消耗回答者精力 BUG解决追踪和及时反馈，这里建议添加“关注或者订阅”功能，解决后能及时反馈给用户。（这里对应小程序的优化） [图片] 顶部建议添加 “疑问/BUG” 选项,为用户提供的处理方法（包括绕过BUG或者hack的方法）和分类。 侧面的“已知问题与需求反馈”，个人觉得很棒，没有问题~ [图片] 3、提问模板+降低沟通成本 3.1、增加提供代码片段的Tips 我之前提了一个问题，就遇到一个情况，官方回答需要我提供 代码片段，当时是一脸懵逼，好在看完教程，知道如何使用了，从此对这个功能喜欢的不得了。 [图片] 个人认为官方给到的代码片段对于用户反馈和解决问题非常有用，所以在官方模板中建议加上代码片段使用方法的tips 小问号ICON~ 3.2、引导/教会 提问者 很多时候“专家用户”想回答一些提问者的问题，但是发现没看明白问题的意思或者误解了问题的内容，这里我认为官方有必要引导提问者更好的描述问题。 一个好的提问者，会让回答者更加省心，所以官方如果能提供一个提问的demo，必然大大降低沟通成本，减少用户抱怨。 [图片] 4、“微信学院”的传道受业解惑 4.1、官方视频指导 首先，需要肯定一点，微信学院这个项目感觉很棒，可以帮助到很多小程序的参与者。 说下问题，现在的界面部分略感凌乱，不同岗位的人进来找于自己相关的教程比较吃力，建议添加分类功能Tab选项~ [图片] 现有的行业分类可以保持（根据你们官方自己的计划来） 功能性分类：产品，开发，运营来区分现在不同种类的视频，因为比如PM过来，他们完全对技术这块视频不敢兴趣，目前就会产生干扰+阅读成本。 建立专辑和连续性：官方的教学视频做的更加“线性”，比如一期二期这种，有规律且连续，类似于专辑/系列视频，这样用户学起来更加持续且扎实，官方教学的效果也更好 增加一些实战类视频（包括技术和运营），目前的视频更多讲的是概念，有点虚，实战较少，比如如何通过云函数生成一个二维码，其实很多人都在问这类问题，这个可以帮助中小企业减低开发成本且更好的社交裂变，对于平台方是双赢的~ 4.2、“文章和问答”的思考 个人觉得文章是传道受业，问答更多是解惑，哪个更重要呢？ 短期肯定是问答，长期的话文章的价值更大，文章凸显的是持续性的知识输出，给开发者提供一个完整的学习路径，比起做到哪里遇到问题再问来说，文章的引导意义更加彻底。 个人觉得官方未来可以考虑鼓励更多的用户去写一些“项目实战和技术贴”，做持续性的内容输出和知识科普~ 5、服务商/插件 5.1、插件接入标准模板 现阶段第三方开发的插件，接入方式和教程参差不齐，有的甚至需要二次开发，但是往往说明不清，给使用者造成很大的困惑。反正本人之前想用一个插件，搜了下各家文档写得各种风骚外加“脑补”，完全被整懵逼~ [图片] 建议官方提供一个标准化的接入模板或者教程，最好带示例，而不是开发者自己想着填，这样可以帮助使用者更方便的接入和使用。 5.2、收不收费的问题 5.2.1、收费 提供“人工服务”的一定要收费，以保持服务的品质 持续性的支持，偏向于收费 需要占用其他资源的，比如地图，服务器，AI算力等 收费的初衷一定是为了提供更好的服务，但希望官方提供一个标准，避免乱定价，或者一锤子买卖坑人的问题。 5.2.2、免费 一次性使用的组件类，不需要其他资源支持，纯粹的代码提供 开源项目 插件，这个有争议，但是插件可能很多情况下，没有“售后”，恐怕出现收费后，撒手不管的情况，容易造成纠纷~ 5.2.3、微信官方支持/支付费用 那些长期维护的项目，或者优秀的开源框架/插件，为了鼓励开发者坚持优化和改进，官方可以提供一笔基金支持日常维护迭代，类似 apache基金会、Nginx社区、React/VUE项目这种，由机构/大公司/基金会维持的项目~ 5.3、建立评价体系 简单的评分和赞踩系统 提供试用/DEMO，上来试用，可以避免买了后发现和自己的需求不匹配的问题 退货/钱功能 谁都不想上来就做小白鼠嘛，花了钱还踩坑~~~ 所以必须建立一个有效的评价体系，也能督促和规范服务商/插件开发者。 以上就是本人的一些拙见，写的比较仓促，如有内容错误和阅读疑惑欢迎各位同行留言评论，觉得不错也可点个赞，让更多人看见，感谢 ^_^ ~