su-chang
commented
4 years ago Thank you for your summary and conclusion.
我希望你们能做了下测试，如果客户端传入了withShareTicket的参数，可以原封不动的带过去给微信。
Sorry to say that we can not supported this option.
I think you can share this issue to Wechaty-Developers-Home and have a discuss with them about the relation between roomID and openGid.
Thank you very much.
微信方机制
官网文档显示，当小程序页面被分享时，如果页面配置了withShareTicket：true，将来用户从群里进入小程序时，就能够拿到shareTicket，最终解密获取到群ID。
可以看出，withShareTicke的生命周期结束之时，就是shareTicket信息的生成之时。
所以这里微信团队就有了两种选择：
①每次发起分享，在选择群时，就判定了withShareTicket，并生成（包括重写）shareTicket信息，附加进了小程序卡片对象里。
②在用户点击卡片进入小程序时，room对象去判定withShareTicket，如果true，就生成shareTicket信息，传入小程序的onLaucn方法，最终开发者通过事件回调拿到shareTicket。
我估计一次分享的关键调用过程和一次进入小程序的关键调用过程应该分别如下面二张图
机器人中断了withShareTicket的生命周期
当采用机器人发送时，其实是越过了用户真实调起客户端分享和目标选择、确认发送等过程，这个withShareTicket参数并没有带上。所以，目前的API，不足以支持拿到群ID。
需求和制约说明
我们想要实现的，是利用wechaty的能力来快捷管理群，为了确保唯一性，群ID是一定要用到的。
目前经过实测，wechaty能拿到的是roomID，类似18596282818@chatroom的一串字符，和小程序正常拿到shareTicket解密出来的是openGId: 'G8r2V5GdQKNotLO0OD97WZBEVfrI'，不同，我估计这两者的关系跟Appid和gh_id的关系有点类似，我注意到对roomID、gh_id进行base64转码之后，位数恰好和openGid、appid一致，可能存在验证关系，做了一些猜测尝试，但是很遗憾，无论是转ascii码的，还是转码后再尝试位运算，都未能得到有效关系。所以，直接通过roomid和openGid挂钩，是走不通了。
但这种情况理论上可以解决，因为可以在机器人发小程序的API上想办法。
如果微信的机制shareTicket是在实际发生时生成，那么wechaty升级API，携带withShareTicket:true，理论上可以解决，当然，如果实际的shareTicket参数是在选择目标对象时生成，那么意味着不可能越过真实发生，机器人拿到openGid就彻底没可能了。
我希望你们能做了下测试，如果客户端传入了withShareTicket的参数，可以原封不动的带过去给微信。
需求场景和重要性
我始终瞄准的是效率工程方向，群已经是多数2B公司的实际客户联系场景，将其纳入管理体系是有必要的。但考虑到机器人本身的不稳定性，我们不能依赖roomID，而应该依赖官方的openGid，让他们建立映射关系。
这很重要，属于客户服务的连续性考量问题。有劳援手。