前情
uni-app是我比较喜欢的跨平台框架，它能开发小程序/H5/APP(安卓/iOS)，重要的是对前端开发友好，自带的IDE让开发体验也挺棒的，现公司项目就是主推uni-app，我主要负责抖音和快手端小程序。
坑位
公司历史原因项目有APP端小程序端，但并不使用uni-app的一端发布所有平台，各端都有它的开发负责人，只有我负责的快手和抖音是基于一套代码发布多端的，因有需求是APP先行的，而基于uni-app的代码利用率还算是高的，于是这一次需求并不是重新从0到1开始开发，而是直接基于App的代码来做调整适配快手抖音端，去除掉一些App特有代码和在解决了一些样式兼容问题后，发现在快手小程序端其中带过滤筛选功能的商品列表显示异常，怎么切换筛选条件都没有更新商品列表。
Why?
在App和抖音小程序端上功能都是正常的，控制台也没有报错，同时也发现接口也是有发起的，于是开始去细看代码，发现App开发者为了组件复用，在商品列表组件有一处逻辑会根据当前是什么路由就请求对应接口，代码如下：
const getCurrentRoute = (index = 1) => {const pages = getCurrentPages()const currentPage = pages[pages.length - index]const currentRoute = currentPage.route; return currentRoute;
}const getList = (params) =>{const curRoute = getCurrentRoute();if(curRoute === 'pages/home/index'){getHotList({...params})}else{getGoodsList({...params})}
}
当时看到这个代码我是比较反感的，为什么要根据路由去判断请求不同接口，直接外面传一个特定的key判断是哪一个页面不是更稳定，虽然代码看着不是很认同，但按理说这功能也不至于一端能用一端不能用，开始怀疑是不是快手端获取路由栈方法getCurrentPages有什么问题，为了定位错误，我通过日志打印查看路由获取是否正确，代码如下：
const getCurrentRoute = (index = 1) => {const pages = getCurrentPages()console.log('---- getCurrentRoute ----:', curRoute);const currentPage = pages[pages.length - index]const currentRoute = currentPage.route; return currentRoute;
}
至此才发现问题所在，在抖音端打印的路由和快手端打印的路由有一小点区别，快手端会在开头多一反斜杠：
解决方案
方案1：比较取巧偷懒的方法就是从返回看pages/home/index是二个都有的，那只判断路由是否包含pages/home/index即可，示例代码如下：
const getList = (params) =>{const curRoute = getCurrentRoute();if(curRoute.includes('pages/home/index')){getHotList({...params})}else{getGoodsList({...params})}
}
方案2：重写不通过路由判断，通过从外面传key判断当前组件是用在哪一个页面，来请求不同的接口，个人觉得此种方式是最稳妥的，也是我推荐的。
思考
小于uni-app跨平台的项目，虽然uni-app已经处理了绝大部分的平台差异问题，但是或多或少会有一些是平台处理漏的，遇到这种一端可以另一端不行的问题，可以先考虑是不是使用了一些平台有差异的API，手动把差异抹平即可,对于实在官方都说明有差异的，那就用好uni-app的条件编译来处理吧。
