两个月写完的校园社交小程序，这是篇uniapp踩坑记录
人员搭配和两个舍友，一前两后，从开发到最终上线，耗时两个月，此篇文章记录一下整个开发流程中踩的坑......
前置准备：
- 资质核验。需要企业认证才能发布社交类的小程序。需要上传营业执照、法人信息等
- 类目选择。小程序中有个类目选择，选择自己小程序涉及的类目，但这里就比较抽象了（下文讲）
- 微信认证。300元，腾子的吃相很难看，但奈何寄人篱下
- 小程序备案。在前面流程完成之后才能进行小程序的备案
审核流程
整个审核流程给我的感觉就是跟便秘一样，交一次吐一句，交一次吐一句，然后打回来重改 这里记录一下几个需要注意的点，如果你和我一样也是做UGC类的小程序的话
- 微信审核。所有但凡涉及言论的，能展示出你的思想的、个性的，对不起，请通通接入微信审核。包括但不限于用户昵称、头像；发布的帖子内容、图片
文字审核算比较快，图片审核就有点慢，且图片审核不是很精准。为了避免等待检测而让用户在界面等待过久的问题，后面无奈自己搭了个后台管理。以致于流程就变成了：用户发点什么东西 -> 后端调用微信检测接口 -> 检测完甩到后台 -> 后台管理员做个二次审核 -> 通过后在小程序获取
- 不能使用微信icon图标。之前做微信快捷登录，想着搞个微信的icon图标好看点，结果给我审核失败的原因就是不能使用微信图标
- 请预留足够的时间和审核慢慢耗。以上讲到的还只是真正发布之前踩的坑，等所有条件都符合后，算可以真正的发布，然后提示你首次提交一般需要7个自然日，然后就真的是7*24小时
5. 第一次代码真正预上线之后，此后更新代码再发布新的包，一半就只需要1~2天
开发过程
- 文件上传。以往网页开发中涉及文件上传的业务都是
new FormData，然后再append必要的字段。但是，小程序中使用FormData会报错，所以，得使用uniapp自带的uni.uoloadFile - 消息提示。在帖子发布成功之后等场景都会涉及到消息提示，一般涉及消息提示、页面回退，执行顺序请按
navigateBack再uni.showToast，如果二者调用顺序反了的话，只会页面回退，不会显示提示内容 - 分享功能。小程序的分享功能需要在
onShareAppMessage(分享至好友)或者onShareTimeline(分享至朋友圈)调用。这两个是和onLoad同级的，如果你的技术选型也是Vue3的话，可以从@dcloudio/uni-app中导入 - 消息订阅。小程序涉及到一个需求：当用户发布帖子，微信审核+后台审核都通过之后会通知用户，此时就需要进行消息订阅
先在微信公众号平台开通消息订阅模板，拿到模板ID，前端中再调用 uni.requestSubscribeMessage 传入拿到的模板ID就可以实现消息订阅
- webSocket。小程序中的树洞评论功能我们选用的是
webSocket，小程序中我们没有使用三方库，调用的是uniapp的uni.connectSocket，创建一个webSocket实例，然后处理对应的回调。由于用户一段时间内如果不发送消息，服务端也就没东西推送过来，webSocket自己会断掉。所以我们引入了心跳机制和断线重连机制。但是在做短信重连的时候就发现一个问题：断线重连之后确实是会创建新的实例，心跳包也正常推送给服务端，但是就是接收不到服务端反推回来的东西，后面经过排查，是webSocket实例的onMessage事件应当写在onOpen中，而不是独立写到外面
独立写到外面进行处理就会出现：断线重连之后死活接不到最新的实例返回的消息
这里再次吐槽微信的内容审核机制。原先选用webSocket的原因就是看中了它的实时推送，但是接入了内容审核就变得很抽象，时而秒通过，时而得等一下，这也搞得失去了选用webSocket的意义
- 请求池。小程序中使用到了tabs组件，当tab在切换过程中，比如tabA切换至tabB，由于需要请求数据，所以页面会有短暂的白屏时间，这里采用的是请求池，在获取第一个tab的列表数据的时候，由请求池顺便把之后的tab的内容也请求回来，此后在进行tab切换时就可以避免白屏，优化用户体验
- 响应式布局。小程序在个人页模仿了小红书个人页的实现形式，也就是随着页面的滚动，页面的布局（主要是用户头像缩小并由透明度为0逐渐变为1）发生变化。一开始采用的是监听页面
scroll事件。但是，scroll涉及大量的计算；后面采用Intersection Observer。但是注意，uniapp不能直接使用这个API，得调用uni.createIntersectionObserver，二者语法差不多 - 防抖节流的使用。页面滚动加载下一页使用防抖，按钮点击进行节流，常规操作。
大概暂时先能想到这么多，后面有想到再接着补充......
后记
其实校园小程序这个题材市面上早已烂大街，说不上有任何的创新。此前决定搞这个的原因有以下几点：
- 很多东西只停留于理论，没有实操。就像webSocket的心跳和断线重连，博客教你怎样怎样，始终不如你自己去亲手实现一下，这个算主要驱动原因
- 这个程序刚好拿去参加学校的比赛，拿奖有钱doge
- ......
然后整一个项目跟下来吧，给我的感觉就是：技术重要吗？重要；但也不太重要，技术的重要性就跟我这句废话一样。因为一个东西，推广不起来，没人用，你就没动力去更新、去维护。当然，有没有人用对我们此次的开发来说还不算是必选项。
大家觉得校园社交类的程序还能集成什么功能，也欢迎提出您的宝贵意见
作者：吃肉不吃皮
来源：juejin.cn/post/7412665439501844490
来源：juejin.cn/post/7412665439501844490
