写在前面的话
我们的后端架构是基于微服务的平台化架构，提供了一套通用的接口，所有的小程序/小游戏都走这套接口，由负载均衡统一分发，这样就需要区分是哪个应用的哪个版本访问的接口，以便准确的处理数据。
解决方案
一、请求时将 `` appid `` 和版本信息放入参数中提交给后端。
优点：简单，直接。
缺点：只能将信息传给后端，而后端无法控制小程序/小游戏端逻辑。
二、使用 <a href="https://developers.weixin.qq.com/miniprogram/dev/api/wx.getAccountInfoSync.html" rel="noopener" target="_blank">wx.getAccountInfoSync</a> 接口获取账号信息。
优点：官方提供的API。
缺点：里面只有 `` appid ``，没有版本信息，存在和 `` 方案一 `` 同样的问题且不支持小游戏。
三、后端获取Referer信息，从里面获取信息。
优点：<a href="https://developers.weixin.qq.com/miniprogram/dev/api/wx.request.html" rel="noopener" target="_blank">wx.request</a> 中 `` 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 | 体验版本 | 扫描体验版二维码或使用 小程序助手 小程序进行访问体验版 |
| 审核 | prod | 审核版本 | 只有审核人员可以访问 |
| 用户 | 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的参数，也可以指定某个人的访问环境。比如测试需要使用线上版本将接口转到测试环境等。
强力驱动