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;