内容摘要：urlscheme获取这事儿，说穿了就是一场和系统玩儿的捉迷藏。你得先知道那个app注册了什么样的协议，才能找到入口。今天早上我帮朋友调一个iOS的跳转，他死活找不到某个笔记软件的唤起参数，最后我翻遍

urlscheme获取这事儿，说穿了就是一场和系统玩儿的捉迷藏。你得先知道那个app注册了什么样的协议，才能找到入口。今天早上我帮朋友调一个iOS的跳转，他死活找不到某个笔记软件的唤起参数，最后我翻遍了GitHub上的开源清单才捞到——原来那家伙把scheme藏在了Universal Links的备用路径里，够阴的。

最直接的办法，是看官方文档。可现实是，大部分开发者文档写得像天书，或者干脆不写。这时候你得学会“偷”。Mac上装个Apple Configurator，把手机连上，抓取描述文件里的URL Types字段。Android那边更简单，用aapt dump badging命令砸开apk，看manifest里的intent-filter。我上次就这么干，五分钟挖出三个隐藏scheme，其中一个还是某银行app的转账入口——当然我只是测试用，别想歪。

要是手上没有开发工具，还有土办法。打开Safari，输入javascript:alert(navigator.userAgent)，然后找个能触发app调用的网页，观察地址栏变化。有个老外朋友教过我，用Charles代理拦截所有HTTP流量，专挑那种带://的字符串。他管这叫“暴力嗅探”，虽然糙，但对付那些没做混淆的app特别有效。

最让我意外的是，很多scheme根本不需要逆向。去URL Testing这类社区逛逛，热心的用户早就整理好了各类app的调用格式。比如微信的weixin://，支付宝的alipay://，连小众的记账软件都有。不过得留个心眼——这些列表更新慢，而且有些是用户猜的，不一定准。我去年就被一条过期的scheme坑过，明明写的是myapp://open，实际新版改成myapp://launch?from=external了。

还有一类特殊场景，就是网页端要唤起桌面客户端。这种通常走自定义协议，但Windows和macOS的注册表/plist文件位置不一样。Windows下用regedit搜“URL Protocol”，macOS则看Info.plist里的CFBundleURLTypes。上周我帮同事调试一个企业IM，发现它在注册表里藏了个callto://的旧协议，估计是抄的Skype代码没删干净，挺逗的。

说到底，获取urlscheme的核心就两条路：要么信官方，要么信自己。官方文档写清楚的最好，省得折腾；写不清楚的，就用抓包和逆向工具自己挖。但记住——拿到scheme只是第一步，能不能唤起成功还得看app有没有做参数校验。有些app防得严，你就算拿到scheme，不带正确的token或签名照样给你弹个“无法打开”的提示。这时候别硬刚，换个思路，试试它的Universal Link或者App Link，往往比scheme更稳。

最后说句掏心窝的话，这活儿干多了容易上瘾。每挖到一个新scheme，就像撬开一扇没上锁的侧门，那种感觉比解开数独还爽。但咱得守规矩，别拿别人的scheme干坏事。我见过有人拿scheme拼出某电商的秒杀接口，结果被风控系统秒封了账号——得不偿失。