做前端最头疼的就是浏览器适配，这次在Universal Link上也一样体现了痛苦。

我本来认为，Universal Link完全是走的系统控制，App应该是无法干预的，但在最初上线的时候就发现UC浏览器和QQ浏览器（非手机QQ）无效，我曾经天真的想这俩浏览器是不是因为自己做了内核不用系统WebView所以可以这样吧，于是乎没刨根问底，这事情就没细究

封禁方案

早上小伙伴给我说微信封杀我们的Universal Link了，我吓了一跳觉得不可能，还以为是小伙伴他点过什么返回原App被苹果策略屏蔽了，直到亲自试了一下才发现，卧槽！是真的！

在试一下知乎/今日头条2款App，也废了╮(╯_╰)╭看来真是下手了这到底是怎么做到的

小伙伴给我贴了个stackoverflow的链接

看到里面有一个回答是这么说明的

sourcecode for WebKit:static const WKNavigationActionPolicy WK_API_AVAILABLE(macosx(10.11), ios(9.0)) _WKNavigationActionPolicyAllowWithoutTryingAppLink = (WKNavigationActionPolicy)(WKNavigationActionPolicyAllow + 2);if you are using WKWebView, just use WKNavigationActionPolicyAllow + 2 instead of WKNavigationActionPolicyAllow

好么~WebKit源码其实本就准备了不触发UniversalLink的控制代码

_WKNavigationActionPolicyAllowWithoutTryingAppLink

只不过这个枚举值是私有的并没有对外暴露，但你会发现这个值等于WKNavigationActionPolicyAllow这个系统公开枚举值+2，于是乎封掉Universal Link的方法呼之欲出了。如果你在使用WKWebView，尝试在decidePolicy的时候返回这个枚举值！

尝试写个demo App，使用WKWebView，然后实现webView:decidePolicyForNavigationAction:decisionHandler:这个delegate，还拿我们的线上universal link页面测试，果然，返回+2了以后 Universal Link是被彻底封堵了

//就是这么的简单粗暴- (void)webView:(WKWebView *)webView decidePolicyForNavigationAction:(WKNavigationAction *)navigationAction decisionHandler:(void (^)(WKNavigationActionPolicy))decisionHandler {    //返回+2的枚举值    decisionHandler(WKNavigationActionPolicyAllow + 2);}

微博上的@Vong_HUST 还跟进逆向了一下

腾讯系的都可以打开，应该是设置了白名单。dump 了一下头文件，也确实发现了一些类似 isCloseUniversallink 的方法，感觉可以投诉到苹果那边了

嘿！看到没？还isCloseUniversallink，这充分说明这TM还是个远程开关，随开随关可控，我说为啥命名微信没发版本，咋就跪了

做用户流量的一条路又废了

我们从自身业务出发，确实想从各种别人的App，别人的浏览器里，往自己App跳，往自己App导流

但换位思考一下如果你是浏览器APP，你是微信，你肯定不希望用户离开微信进入别的App，因此最早Schema式跳转是被各大浏览器老早就封杀的

最早还寄希望于Universal Link是系统机制，或许封杀不到，然鹅......

让我们猜猜，手百的Universal Link，还能活多久？