后端总说他啥也没动，我从线上调了一下测试接口，你再说一句动没动

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

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

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

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

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;

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

-----------------------------------------------------------------------------------------

看着不过瘾？技术型爽文推荐：

后端接口时通时不通，团队全链路排查实战

-------------------------------------------------------------------------------------------