URL Schemes 是个可以称得上「古老」的自动化方式了，它从 11 年末就迎来了它的第一次高峰，四舍五入，我们已经用了它快 10 年了。但是一直以来，没有人尝试过系统地把 URL Schemes 的使用方式讲明白，这让 URL Schemes 变成了「麻瓜」和「魔法师」的分界线，也让我们这些非程序员但对自动化感兴趣的普通用户感到无从下手。
第一篇文章为理解 URL Schemes 确立框架
于是，在 2015 年 10 月 10 日，当时自以为把 URL Schemes 研究得比较透彻的我，写了一篇《URL Schemes 使用详解》。在这篇文章里，我根据自己的理解，把 URL Schemes 分为了以下 4 种类型：
- 基本 URL Schemes：用于启动应用的 URL，例
alipay:。 - 复杂 URL Schemes：用于启动应用特殊界面的 URL，例
alipayqr://platformapi/startapp?saId=10000007（支付宝扫码）。 - 变形 URL Schemes：Launch Center Pro、Drafts 等第三方应用各自对 URL 的特殊改造，例：Launch Center Pro 中的列表或 Prompt 用法。
- x-callback-URL：用于跳回上一个应用或者跳向下个应用的 URL
这 4 种类型为理解 URL Schemes 建立了一个框架。在当时，只要是 URL Schemes，都在这个框架之内。
这是我自己理解事情的方式，我讨厌盲人摸象，讨厌摸着石头过河。所以在详细理解一个事情之前，我会为其建立一张「地图」，这样我就能在涉及到一个知识点的时候，知道它在这张地图上属于什么位置，和它关联的东西是什么。这样更容易把琐碎的知识点，看似无关联的知识点联结起来。有助于理解，也有助于记忆。
也就是说，这篇文章在我看来，最主要的任务就是完成了理解 URL Schemes 的框架。为了让文章更好读，也因为我素来的「结案」野心，我把 URL Schemes 的前因后果，发展、编码问题以及查询方法也都写在了这篇文章里。如果认真读过这篇文章，关于 URL Schemes 就不会问出不该问的问题。
所谓不该问的问题，并不是指小白问的问题。其实小白问问题并不可恶，我在文章里和播客里都表示过，一个领域的高手会忘记他学习时碰过的壁，而半吊子会不懂装懂，只有新人经常会问出很本质的问题。
那么什么叫不该问的问题？不该问的问题，可以体现出提问者根本没有为解决这个问题付出任何一点努力——他没有调查，也没有尝试，甚至搜都没搜过。如果一个人自己都不愿意为自己的问题付出努力，就失去了要求别人为其努力的资格。
所以要熟悉和入门 URL Schemes，《URL Schemes 使用详解》这篇文章还是有必要粗读一下。大概了解 URL Schemes 的框架和它的由来，这样就能明白它的限制。关于 URL Schemes 的不该问的问题，就是提出一些根本不在 URL Schemes 能力范围内的需求。
