◇  不知道广大前端同学有没有过这样的经历，在做新需求联调的时候，原本上一个版本已经做的好好的功能，前后端已经联调好的。这次做需求的时候，测试发现好多地方都不对了。

        ◇ 开发人员经常说的一句话就是：我啥也没动啊。这次就是，我们这个后端，一口咬死，我啥也没动，要不你问一下前端是不是动哪里了？

        如果这个时候你再和他争吵下去就像极了这个图片一样，两个人都张大了嘴，来吧，我们互相伤害。 

        因为是在测试环境，大家都做了新需求，谁也不敢保证自己没动，所以这个时候争吵是无意义的。那么幸亏我提前准备了一招。

 

1、现在前端是怎么区分测试环境与线上环境的？ 

        其实这个问题现在是一个普遍现象，之前也说过好几次了。

        △ 大家都是通过npm run build /prod来区分环境的，所以如果准备测试的时候，我们很高兴的终于做完需求了，打了一个npm run build包，开始部署。

        测试阶段完了，测试同学说，咱们往测试环境部署一下正式包吧，验证一下线上环境的接口。然后我们又npm run prod一下，然后部署上去。测试验证过后，喊一声没问题了，发报告吧。发完收到通知，然后我们就开始把刚才npm run prod那个包部署到线上去。

        但是线上那个包，貌似验证不了测试环境吧？

 

        △ 还有一种方式呢，就是前端不做处理，把HTML做到服务端进行渲染。服务端是可以区分测试环境的机器与线上环境的机器的，所以我们前端只要打一个包就可以，不用区分测试与线上环境。只要服务端识别到是测试机器，还是线上机器，就可以在HTML页面帮我们渲染一个区分变量，我们前端用以区分请求环境。

        但是一但到了线上，貌似线上的js还是没法往测试环境发请求吧？

 

2、为什么要从线上往测试环境发请求？

        这也是出于周全考虑的一种策略行为。试想，在开发新需求的时候，如果后端的接口名字没变，只是参数变了；或者后端的接口没变，参数没变，逻辑变了？再或者后端直接把接口名字给变了；每一种情况其实都会有一定的危险的，所以，能不上线就不上线。

        比如后端把接口名字变了，我们没有反应及时，或者沟通不及时，那么这个时候的上线过程必定是要出问题的。

        比如后端参数变了，那么试想，我们前端先上线，线上的接口会不会不适应的新版本的js，服务端先上线，会不会接收不到前端的新参数而不适应。就会变得像下面这张图一样，造成扭曲的情况。

 

        虽然每次我们所做的功能都应该是向后兼容的，但多做一些测试措施总是没错的。

 

3、线上怎么向测试环境发请求？

        △   例如测试环境的请求前缀是  test.xx.com/api    而线上环境的请求前缀是 prod.xx.com/api

        △   那么我们前端一定是要有地方适配这2个前缀的。

        △  比如我们的网站访问地址为： www.ooo.com 这个时候调用的一定是prod.xx.com/api的请求域名

        △ 这个时候我们手动给url加个参数 例如 www.ooo.com?test=ok

        △ 这个时候如果没有任何操作，其实这对我们网站是没有任何意义的，但是我们可以在js的代码里做适配

function geturlparam(key){
   let url = window.location.href;
   let params = url.split('?')[1]
   let getParam = new URLSearchParams(p);
   return getParam.get(key);
}
var testOrProd = geturlparam('test'); 
let urlDomain = '';
if (testOrProd === 'ok') {
    urlDomain = 'test.aa.com/api';
} else {
    urlDomain = 'prod.aa.com/api';
}

module.exports = urlDomain;

通过这种线上环境向测试环境发请求的方式，是不是就可以做到另一个维度的测试了呢