◇ 不知道广大前端同学有没有过这样的经历，在做新需求联调的时候，原本上一个版本已经做的好好的功能，前后端已经联调好的。这次做需求的时候，测试发现好多地方都不对了。
◇ 开发人员经常说的一句话就是：我啥也没动啊。这次就是，我们这个后端，一口咬死，我啥也没动，要不你问一下前端是不是动哪里了？
如果这个时候你再和他争吵下去就像极了这个图片一样，两个人都张大了嘴，来吧，我们互相伤害。
因为是在测试环境，大家都做了新需求，谁也不敢保证自己没动，所以这个时候争吵是无意义的。那么幸亏我提前准备了一招。
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;通过这种线上环境向测试环境发请求的方式，是不是就可以做到另一个维度的测试了呢