写在前面的话

我们的后端架构是基于微服务的平台化架构，提供了一套通用的接口，所有的小程序/小游戏都走这套接口，由负载均衡统一分发，这样就需要区分是哪个应用的哪个版本访问的接口，以便准确的处理数据。

解决方案

• 一、请求时将 appid 和版本信息放入参数中提交给后端。
  优点：简单，直接。
  缺点：只能将信息传给后端，而后端无法控制小程序/小游戏端逻辑。

• 二、使用 wx.getAccountInfoSync 接口获取账号信息。
  优点：官方提供的API。
  缺点：里面只有 appid，没有版本信息，存在和 方案一 同样的问题且不支持小游戏。

• 三、后端获取Referer信息，从里面获取信息。
  优点：wx.request 中 header 内 Referer 的值是默认生成不可以设置的且格式固定。
  缺点：无法区分开发版本、体验版本和审核版本， 方案一 的问题依然存在。

• 四、自己维护版本信息，提供一个远程的版本信息同步接口。
  优点：可扩展性高。
  缺点：开发时需要定义版本信息，小程序/小游戏每次打开时都需要同步版本信息。

最佳方案

我们选择了 方案三 配合 方案四 来实现，主要原因是因为 wx.request 中 header 内 Referer 的值是默认生成不可以设置的且格式固定，并且里面包含了 appid 和 版本号 [小程序自己的版本号，并不是我们自己定义的版本号，且只有线上版本的] 的信息。小程序/小游戏端无需增加参数后端即可获取这些信息。

Referer 的格式固定为：

https://servicewechat.com/{ appid }/{ version }/page-frame.html

其中 { appid } 为小程序的 appid，{ version } 为小程序的版本号，版本号为 0 表示为开发版本、体验版本以及审核版本，版本号为 devtools 表示为开发者工具，其余为正式版本。

以上描述摘自官方文档 网络 的章节

开发版本、体验版本以及审核版本的 version 都为 0 ，然而在开发过程中后端分为 dev 、test 、uat 、prod 等不同的环境，只使用 方案三 并不能完美的解决问题，这种方式前端并不能获取到当前版本的状态，无法动态的切换访问的环境，如果都去通过负载均衡去分发，反而给负载均衡带来了压力，所有环境都部署在外网也不现实。

于是我们想到了一个解决办法，也就是 方案四，自己维护版本号。通过版本状态来判断当前版本需要请求的环境。

实现思路

小程序/小游戏分为开发版本、体验版本、审核版本和线上版本。

• 开发版本是由开发者进行上传才可以访问的，开发者工具模拟器、预览和真机调试的不会出现在这里。
• 体验版本是由管理员选定某个人提交的开发版本作为体验版的。
• 审核版本也是由管理员选定某个人提交的开发版本进行提交审核的。
• 线上版本是审核版本审核通过后，管理员进行发布的。

不同角色的人员如何访问对应的版本

小程序/小游戏端定义自己的版本号，新版本开发时，版本号进行升级，同时后端数据库中添加当前开发中的小程序/小游戏版本号，并标识当前这个版本号的状态为 dev 开发阶段，提交测试时将版本号的状态修改为 test 测试阶段，用户验收时将版本号的状态修改为 uat 验收阶段，后续版本的做法以此类推。
后端提供一个接口，小程序/小游戏端打开后，首先调用这个接口进行状态同步，参数为当前的版本号，接口返回版本的状态。小程序/小游戏中通过硬编码的方式，根据状态来判断当前需要访问的环境地址。

需要后端先上线版本号管理的功能。

每个环境中的接口 pathname 是固定不变的，会变动的只有 origin。
举例：

生产环境中的一个接口 https://examplp.com/api/login
验收环境中的一个接口 http://10.10.10.10:8080/api/login
测试环境中的一个接口 http://192.168.1.100:8080/api/login
开发环境中的一个接口 http://localhost:8080/api/login

其中 /api/login 为 pathname 是固定不变的，变动的只有前面的域名也就是 origin，小程序/小游戏端只需要根据版本号的状态去修改 origin 就可以了。

注意：使用这套方案时，一定要防止版本信息同步接口过度依赖而影响主业务的事情发生，请做好兼容处理。

功能扩展

通过这套流程不但可以动态的切换小程序/小游戏端访问不同环境的后端接口，还可以动态的停止线上的某个版本。

接口再扩展一个 openid 的参数，也可以指定某个人的访问环境。比如测试需要使用线上版本将接口转到测试环境等。