小程序的分享票据，可以理解为每一次分享的一个唯一ID。有什么用处呢？太有用处了，比如分享到群。
怎么获取这个shareTickets呢？有两种方式
1、分享的回调里
onShareAppMessage: function (res) {
if (res.from === 'button') {
// 来自页面内转发按钮
console.log(res.target)
}
return {
title: '自定义转发标题',
path: '/page/user?id=123',
success: function(res) {
res.shareTickets // 单聊是没有的
},
fail: function(res) {
// 转发失败
}
}
}
2、app的onLaunch
App({
onLaunch(res){
res.shareTickets
}
})
注意必须要在分享前调用wx.showShareMenu方法，否则是不会带分享票据。
最初的版本是只有这两个地方可以获取分享票据的。但是这个的设计是极其不合理，为什么呢？因为onLaunch的回调场景有限制。
当小程序初始化完成时，会触发 onLaunch（全局只触发一次）
全局只执行一次，所以第二次进来是不会执行。当然我们有办法，可以缓存shareTickets。可是，一旦在群里多次分享，shareTickets的管理就变得极其蛋疼，可能会取不到第二第三次分享的shareTickets。
这是个很大的坑，后面官方又在onShow的回调中加入了获取shareTickets的逻辑，这次应该可以避免这个问题。
分享票据的有效期
官网文档没有明确的说明有效期，实际操作过程又遇坑。getShareInfo是用shareTickets去换取加密信息，这个加密信息有什么用？获取群ID。
换回的encryptedData和iv加密信息传给后台处理解密。
encryptedData才会有有效期，有效期过期了怎么办？重新getShareInfo是无效的，必须重新wx.login。
我们的请求流程是这样：
- 进入小程序页面，onShow
- wx.login成功
- 获取shareTickets
- getShareInfo换取encryptedData
- 请求CGI，POST发送encryptedData
- 后台处理请求，返回给前端
- 如果encryptedData失效
- 重新wx.login
- 继续后面的逻辑
一个完整的请求链太长了，导致用户体验并不太好。我不知道小程序框架设计有没有考虑这一点。
层层回调嵌套，简直反人类。
getShareInfo
这个有什么坑呢，不能频繁请求，应该算是一个坑吧。千万不要在setInterval这里面调用这个接口。先缓存住加密encryptedData数据，如果过期，则重新getShareInfo。
即使不过期，也不要频繁请求，因为getShareInfo耗时200-300ms，等不起。
单聊和群聊
单聊是无法获取到shareTickets，总觉得以shareTickets来区分单聊和群聊场景是不太合理的事情。
不要说还有sence的值，那个只在onLaunch回调里面才有。
shareTickets用处就是可以在群里玩小程序。比如常见的群公告，群打卡。说白了，就是让普通开发者拿到群ID。具体小程序，大家可以搜搜看。
