今天不聊中间层，我们来聊聊中间页_编程技术

今天不聊中间层，我们来聊聊中间页

背景

平常代码编程中我们会碰到一些交互问题 or 团队间的合作问题，需要处理链接跳转之间的问题，假如我们作为提供方，需求方来自不同的业务团队，甚至有时来自第三方。当然不仅限于此，还有很多令人脑壳疼的场景，这时候我们可以提供一个中间页作为对接桥梁，在此页面去揽下所有对接的活。但针对过渡页的合理使用和一些注意事项，我这里想单独拎一篇小文章出来说说，继续看看吧。

使用场景

1: 不确定的多方业务方或者不同渠道业务方

假如我们作为提供方，会面对不同的业务方，一部分来自于不同的协作团队，一部分来自不同的渠道(微信、小程序、app)，这时候中间页就该上场了，由它来负责，主要根据 query 参数去做跳转逻辑处理，负责跳到具体的目标页 A、B、C 等等。目标页理应来说只负责该页面具体的逻辑，不该外揽下其他的脏活，下图为简易版场景图。

![1901638101967_.pic](/Users/huangqin/Library/Containers/com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/2.0b4.0.9/a301252f4cfd6c12512699071071e4d7/Message/MessageTemp/9e20f478899dc29eb19741386f9343c8/Image/1901638101967_.pic.jpg)

思路：在中间页你可以针对不同的 query 去做处理，目标页放在 targetUrl，在处理对应的逻辑结束之后，跳转到目标页。这时候用户其实是无感知的，如下是简易版 code。

注意：我们作为提供方，最好能能提供一个标准模版，例如 appid 专门用来区分来源，来源的定义尽可能标准化，targetUrl 用来存在跳转 url，跳转到中间页 token 处理，都是需要提前定义好的，这些 query 参数基本是统一的。so 最好是能对外提供一份对接文档，注释尽可能详细(包括 code 中), 这样避免自己踩坑(排查问题 or 撕逼。。。我太难了)

// 这里例举一个数组，假如针对 query 需要处理的逻辑
const fnList = [
['appid', 'handleAppid'],
['token', 'handleToken'],
['payUrl', 'handlePayUrl'],
['sourceId', 'handleSourceId'],
...
];
mounted() {
this.handleQuery();
// 处理完跳转到目标页志华，跳转到目标页 target
if (this.query.target) {
location.replace(this.query.target);
}
},
// 具体的 handleQuery 操作
handleQuery() {
// 这里你可能有一些前置处理
......
// 对 query 进行处理
fnList.forEach(([key, fn]) => {
if (this.query[key] && this[fn]) {
this[fn]();
}
});
},

2: 同一业务方但有定制化需求的场景

听起来和第一种场景很像，但是有差啦。假如作为提供方，都是同一个对接方，但走的模式不同，导致后续业务流程不一样。拿图片中的例子来说，目标页是根据类型前置不同的目标页面，这里 query 的参数会根据 type 的不同，会携带和其 type 对应的业务参数，这种提供的目标页是一样的，但参数会依赖业务自身需求而定。

![1941638105158_.pic](/Users/huangqin/Library/Containers/com.tencent.xinWeChat/Data/Library/Application Support/com.tencent.xinWeChat/2.0b4.0.9/a301252f4cfd6c12512699071071e4d7/Message/MessageTemp/9e20f478899dc29eb19741386f9343c8/Image/1941638105158_.pic.jpg)

简易版 code 如下：

// 根据 type 类型区别业务来源
checkType(type) {
return this.query.type === type;
},
mounted() {
// 可能有一些前置操作
......
this.handleQuery();
},
// 具体的 handleQuery 操作
handleQuery() {
// 这里你可能有一些前置处理
......
// 来自服务包，需要带上 sourceId 参数
if (this.checkType('serverPack')) {
const newQuery = {
sourceId: query.sourceId,
...
};
this.$router.replace({
name: 'orderServerPackConfirm',
query: newQuery,
});
return;
}
// 来自 XXX 的信息，需要将 osTokenId 带到确认页
if (this.checkType('pcDetail')) {
confirmQuery.osTokenId = this.query.osTokenId;
}
// 其他
.....
this.$router.replace({
name: 'orderConfirm',
query: confirmQuery,
});
},

3: 处理跨域请求或参数需要由接口提供的情况

前面两种情况不论是 1or2，基本上我们说的是由 query 显性传递，但是也会有部分场景我们可能不再适用，如下

1：参数过多 or 或者对应的某个参数值过大不适用 query 的方式传递，采用接口调用方式，由中间页自行获取其中必要的参数即可。

2: A 应用跳到 B 应用，此时两个应用存在跨域问题，A 需要调用某接口，内容值存在 cookie/storage 中，需要将其内容传送到 B 应用中使用。应对这种情况，可以在跳转到 B 应用的过程中加一个前置跳转中间页，这时 A 只负责跳转到中间页，将其调用的接口入参传入到中间页，在中间页去请求接口，这是内容值就可以稳定存储在 B 应用中了。

简易版 code 如下：

// 校验 query 需要
checkQuery(keys = []) {
return keys.every((key) => !!this.query[key]);
},
// 根据 type 类型区别业务来源
checkType(type) {
return this.query.type === type;
},
mounted() {
// 可能有一些前置操作
......
this.handleQuery();
},
// 具体的 handleQuery 操作
handleQuery() {
// 这里你可能有一些前置处理
......
// 商详
if (this.checkType('detail') && this.checkQuery(['skuId', 'quantity'])) {
// 接口在中间页去请求
data = await this.directBuy({
skuId: +query.skuId,
quantity: +query.quantity,
});
}
// 购物车
if (this.checkType('cart') && this.checkQuery(['shopcartId'])) {
// 接口在中间页去请求
data = await this.submitCart({ shopcartids: JSON.parse(query.shopcartId) });
}
// 其他
.....
this.$router.replace({
name: 'orderConfirm',
query: confirmQuery,
});
},

使用中间页的一些注意点

1: 不要滥用中间页

中间页在某些业务场景下确实能帮我们解决一部分的逻辑抽离问题，至少面对以上几种场景不用再去担心某些情况下给哪个业务方爸爸去提供不同的目标页，但是我们还是要根据项目中实际情况去评估使用一个中间页的必要性，至少我们应该保持着：必要性、业务耦合度、可扩展性的角度去理性编码，滥用中间页后期可能就会出现中间页到中间页的跳转(不同开发可能写了跳转页逻辑，已经是个公共的页面)，由于文档不清晰或者更新不及时等原因，反而可能后期维护性成本更大，这是我们需要注意的一个问题。