fallback 链接更新后没有起作用

[zgh0711]

如题，我在修改了fallback地址后，唤端失败还是跳转的以前设置的链接，新修改的链接没有起作用，不知道这是什么原因，求解答

[suanmei]

是不是你的项目本身有缓存，你看下你加载的 js 中传入的地址是否是新的 fallback
最好是有debug后的截图，否则猜不出来的😊

[zgh0711]

断点后看到的都是压缩之后的代码，完全没法看啊。。。。

[zgh0711]

我的是 Vue 项目，其他代码改动了马上就能看到效果，我在调试面板里面看到 vue 组件里面，fallback 的链接是改了，但是点击后并没有跳转到新设置的链接

[suanmei]

我刚给 rollup-plugin-uglify 的作者提了issue，这样我可以一次构建出两份文件，一个未压缩的，一份压缩的。

现在我先手动构建出两个文件，把入口文件改为未压缩版本，这样你就可以 debug 了。

然后你把你的配置的 options 截一下图，当然，这个不会涉及到什么机密。

你再注明一下是在什么系统什么app(浏览器或者其他..)遇到的这个问题。

这样才能帮你排查

[suanmei]

@zgh0711 问题定位到了吗

[zgh0711]

我还没定位到问题，先贴下我的配置和调用代码

const CallApp = require('callapp-lib');
        const option = {
          protocol: 'youpeng',
          intent: {
            package: 'com.ypl.meetingsharec',
            scheme: 'youpeng',
          },
          // universal: {
          //   host: 'm1.youpenglai.com',
          //   pathKey: '',
          // },
          appstore: 'https://itunes.apple.com/cn/app/id1238992209',
          yingyongbao: 'http://a.app.qq.com/o/simple.jsp?pkgname=com.ypl.meetingshare',
          fallback: 'http://a.app.qq.com/o/simple.jsp?pkgname=com.ypl.meetingshare',
        };
        const callApp = new CallApp(option);
        callApp.open({
          path: ''
        });

universal 因为iOS那边没弄好，所以我先注掉了

[zgh0711]

你如果要用我上面的配置去测试的话，现在是测不了的，因为我们线上的 App还没有更新，用线上App现在测不了

[suanmei]

唤端失败还是跳转的以前设置的链接

以前的链接是什么呢

[zgh0711]

最开始我是复制的你的代码，所以一直是跳转到了电流，后来过了二天就正常了，
后来我再改fallback链接发现又出现了没有跳转到新的fallback链接的问题，然后过了二天就又正常了，，，
这问题很诡异，我不知道怎么会这样。
要说是缓存的问题，我觉得也不是，因为我这是Vue项目，而且我也没有设置缓存策略

[suanmei]

组件本身是没有存储 fallback 的，所以执行的时候只会从页面加载进来时初始化 callapp-lib 时你传入的 options.fallback 中取，所以打开旧有链接和 callapp-lib 是无关的

[zgh0711]

如果其他人都没有这个问题的话，那估计就是我这边的问题了。
但是我真的不知道哪里有设置过什么缓存逻辑，尴尬。。。
或者有没有可能是服务器那边的配置问题导致的，我去问下，不过估计是问不出来什么结果的。。。。。。

[suanmei]

页面资源加载，js 文件名都带 hash 值了吗

[zgh0711]

打包的时候都是webpack自动加了hash的，

[suanmei]

你可以本地再尝试改一下 fallback 的地址，为 https://www.baidu.com 看看唤端失败跳转地址会不会立即变化，如果没有的话，debug 也是能 debug 出来的

[zgh0711]

我现在在浏览器里面调试的时候始终无法跳转到 fallback 的链接，调试到 evokeByLocation 这个方法时发现 URL好像不对。

然后就走到 return open 方法了

我这是模拟安卓手机测试的，如果是iOS的话，会在跳转到AppStore的时候一直报错

截取了三个请求的内容，分别为：

[suanmei]

你是在电脑上用谷歌模拟的吗，最好不要这样，唤端还是得在手机上去测试，然后安卓用 chrome 的 chrome://inpsect/ 去调试，ios 借助 safari 调试。

你既然模拟安卓了，callapp-lib 检测到了系统为安卓并且是 chrome 浏览器，就会打开 intent URL，而不是 scheme。所以你第一张截图中地址是没有问题的，包括fallback改为了测试所用的百度。

[suanmei]

模拟 ios 报的几个错误第一个是没有问题的，scheme 打不开，就是会这样，status 为 calceled
后面的两个 itunes:// 是正常的链接， itunes:// 重定向到 itmss:// ， itmss 是要用来打开 itunes 客户端的。
如果你的电脑上有 itunes，是有这样的confirm框的

我现在测试出来发现，ios 上 scheme 唤起 app 的confirm框如果选否的话，会导致 itunes URL 无法唤起 app store，所以 ios 上，对 scheme 做了很多限制，能用 universal Link 尽早用。

[zgh0711]

嗯嗯，了解了，多谢大佬