微信小程序通信模式

小程序的场景，获取用户数据的方式有所不同，应用服务器不能直接向微信服务器请求数据，而是由小程序向微信服务器获取，微信服务器会将数据使用一个密钥加密，返回给小程序。小程序没有密钥、无法解密这段数据。小程序将该加密数据发送给应用服务器。应用服务器也没有解密密钥，但可以通过一套流程来获得解密密钥。下面是小程序场景中获取用户数据的流程：

调用 wx.login() 函数 [小程序内部逻辑] 小程序访问微信服务器 wx.login() 相应的接口 [小程序内部逻辑] 返回 code 将 code 给应用服务器 调用 code2session 接口 返回 openid 和 session_key 此时应用服务器已获得 session_key，流程结束 ok

opt [获取解密密钥] 调用 wx.getUserinfo() 函数 [小程序内部逻辑] 小程序访问微信服务 wx.getUserinfo() 相应的接口 [小程序内部逻辑] 返回加密的用户信息数据 将加密的数据交给应用服务器 应用服务器使用 session_key 解密数据

ok

opt [获取用户数据] 小程序 应用服务器 微信服务器

为何微信 H5 应用（见：微信 H5 通信模式）和小程序应用的数据交互模型不同？微信做这个决策的主要原因我们比较难以猜测，但主要因素肯定是安全和便利性方面的综合考虑，此外还与小程序的应用场景有关。

最初小程序发布时，其面对的场景就是低频、短时的场景，例如饭馆点菜、瑞幸点咖啡，点完就结束。小程序发布之初并不考虑用户需要长期交互式使用的场景，或者说，小程序的运营方并不需要用户长期停留，也不期望用户会日常打开小程序，所以通常情况可以不用考虑长 session 的场景（早期小程序不支持搜索、不支持分享，只能在线下现场扫码打开），这种场景下，微信也并不鼓励应用有“登录”的需求。后来可能由于市场对小程序的理解与微信团队不一致，可能因为小程序的使用体验比 H5 好，所以大家开始扩展小程序的使用场景，例如知乎尝试过用小程序，这种需求就需要有长期的 session。

这篇关于微信小程序通信模式的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持