勤勤恳恳的业务推土机。最近接了一个同事的需求，需求开始一切推进正常。但是走到业务深处。发现tab切换，竟然是通过走路由，加载不同业务模块。简直就是离谱。所以离谱的解决方案也就来了---如何获得来源页面的url？

离谱的老代码

现在老业务中有一个tab组件，暂且用A、B、C做区分。原本只有A｜C两个Tab，由于本期需求，是要在中间加一个Btab用作新需求的落地页+列表页。之前A落地页是跳进新路由内完成业务，点击保存或者取消后，直接使用了history.go(-1)。所以这样返回当前页，看着确实没问题。但是现在新需求的落地页与老组件相似的很。而且开发日期压缩的也很厉害，目前只能复用A的相关模块。但是路由肯定是新的。代码写到这里一切还算正常。但是当从B落地页回来再使用history的api虽然也能返回，但是tab页的选中就会被重置成为A的。这样就会有问题，点击Btab页下的落地页按钮，跳转到新路由模块，操作完后我们返回了Atab下的列表页。所以，就需要知道go(-1)的来源页。然后主动click()对应的组件。

离谱需求的调研

首先，就是研究了history这个api的用法，看是否有符合要求的。history常用的就是forward、back和go这三个。但是这三个api分别是前进、后退，以及根据下标比较看到达history历史中的某个页面。这里要注意的是go在使用的时候，会把当前页当作0，如果是-1就会返回上一页2则会向前进两个页面。虽然history能帮助我们到达对应页面，但是它并不能给我们来源页信息。只能放弃。\
其次，用于老项目用的dav/router，立马想到了router中history可能有别的玩法。于是，一研究发现，果然push方法可以传递数据，例如：this.props.history.push({url, data})。但是我们要的是go返回data。尝试发现，并没有用。只能独自怀疑离谱需求的科学性。\
最后，也是最后一次尝试。那就是使用Document.referrer。刚在社区里看见时，喜出望外，觉得这次一定成了。结果证明，虽然他能返回url，但是确实当前url的域名。具体原因还待研究。