支付宝Scheme跳转大全：从抓包到验证的完整指南

简介：支付宝已开放 scheme 大全是一份面向移动端开发者的跳转规则清单，内容来自对支付宝 APK 的解析提取，覆盖扫一扫、蚂蚁森林等高频场景的唤起入口，可用于 URL 跳转、外链拉起或自动化测试脚本。压缩包内共 2 个文件，合计 62KB：json 文件保存 scheme 与 saId 的数字对应关系，key 位置的数字即所调用的 saId，按需替换后即可完成指定页面跳转；xml 文件则提供易读的规则视图，方便排序筛选、二次整理或导入其他工具。目前已有 5734 人学习下载，适合需要集成支付宝跳转能力、研究客户端路由规则或编写批量验证脚本的开发者直接取用。需要留意的是，json 中少部分条目源于早期活动，实际唤起时会提示服务已暂停，使用前应过滤失效地址；剩余可用条目以数字 key 组织，能按场景快速检索，并配合示例 scheme 做真实环境验证，大幅节省从 APK 中逐条反查跳转入口的时间。

1. 为什么需要一份支付宝scheme大全：从一次跳转需求说起

上周有个做H5活动页的A同学找我，说客户要求从网页按钮直接跳进蚂蚁森林浇水，结果翻遍支付宝开放平台文档只看到支付和登录两个入口，最后只能靠抓包把alipays的scheme一点点挖出来。这种事我见过太多次：官方文档不列完整清单、网上答案普遍过时、App一更新请求就静默失效。这篇就把「整理支付宝已开放scheme」的完整思路、验证方法和一份我自用的清单模板拆给你，帮你绕开答应客户三天交付、最后一天还没搞定跳转的死局。适合做营销页、客服机器人、跨端导流的开发者，也适合想搞清App间跳转安全边界的同学。你不需要是逆向高手，只要有一台Android手机、一个抓包代理和一点耐心，照着做就能拿到自己可复现的scheme清单。

2. 先搞懂scheme怎么来：从抓包到反编译的三条链路

2.1 分清scheme的三个来源：官方文档、抓包、反编译

我第一次搞支付宝scheme也是到处搜，后来发现来源其实只有三类，稳定性天差地别。

第一类是官方文档。支付宝开放平台确实公开了一部分跳转协议，但基本集中在支付、授权、加好友这些营销场景，像蚂蚁森林、账单明细、卡包这类生活服务入口，文档里要么不提、要么藏在某个不起眼的边角。优点是权威，参数定义清楚，缺点是覆盖太少，根本撑不起「大全」两个字。

第二类是抓包。这是我最常用的路子：手机连上代理，在支付宝里点目标功能，就能捕获真实的scheme。抓到的是客户端当前版本真正在用的协议，准确性最高，而且能看清参数怎么拼。缺点是只能抓到「被你点过的入口」，没点到的就漏了。所以抓包适合验证，不适合穷举。

第三类是反编译APK。把支付宝的Android安装包拖进反编译工具，在AndroidManifest.xml里过滤alipays，能挖出一大批scheme，覆盖最全。但这里有个大坑：客户端里大量路由是内部专用，带着无法通过校验的参数，直接拉起来要么闪退、要么跳回首页。所以反编译只能作为线索来源，最终必须回到真机端到端验证。

我的习惯是三步走：先用反编译拿候选清单，再用抓包确定真实参数，最后用adb命令逐条拉起验证。这个顺序能让你既不漏项，又不会被内部路由浪费时间。

2.2 抓包定位scheme：从点击到拦截的五个操作

抓包工具我用过Charles、Fiddler和Whistle，原理都一样，选一个顺手的就行。下面以Whistle为例，因为它的命令行过滤对scheme这种长协议特别方便。

第一步，电脑和手机连同一个局域网，手机WiFi代理指向电脑的8899端口。注意，只做scheme抓包其实不需要装根证书，除非你要解HTTPS的body；scheme本身在请求行里就是明文，不涉及证书解密。

第二步，打开Whistle的Network面板，先加一条过滤规则，只保留alipays相关的请求，避免支付宝几十个HTTPS请求把面板刷爆。

# Whistle规则写法：把alipays请求单独抓出来 alipays:// whistle.keephost://com.eg.android.AlipayGphone

这里解释一下：whistle.keephost是让匹配到的请求保留host不被合并，方便你按包名区分支付宝和别的App。第三步，回到手机打开支付宝，依次点扫一扫、蚂蚁森林、账单、卡包这几个你想拿到的入口，每个动作停留两秒，让请求发完。

第四步，回Whistle面板，你会看到形如alipays://platformapi/startapp?saId=10000007这样的记录。把host、path、query三部分完整抄下来。第五步，用adb命令在电脑上直接拉起验证，确认它不是个死链。

# 在电脑上通过adb验证支付宝scheme是否可跳转 adb shell am start -a android.intent.action.VIEW -d "alipays://platformapi/startapp?saId=10000007"

这条命令的-a指定Intent的Action为VIEW，-d传数据URI。如果命令执行后手机弹出支付宝并进入扫码页，说明scheme可用；如果半天没反应，可以在终端看报错信息，常见的是ActivityNotFound，说明支付宝没注册这个路由。

2.3 批量验证scheme的「三看」规则

拿到一批scheme后，不能全信，得逐条验。我的经验是看三个地方。

一看包名。合法的支付宝scheme，跳转目标必须是com.eg.android.AlipayGphone，如果拉起的是别的包，那要么是scheme被劫持，要么是你从网上抄的旧协议花了眼。

二看params参数。同一个业务入口，params里塞的键值不同，落地页可能完全不同。比如账单入口，传timeRange=0是本月，传timeRange=1是近三个月，这个只能靠抓包对齐，不能靠猜。

三看兜底行为。很多scheme带着url=http%3A%2F%2F这类的参数，含义是当App没装或路由失效时，直接startApp失败后改开这个H5地址。如果抓包抓到这类冗余参数，务必检查兜底链接是否还能访问，否则用户跳不过去时会看到一个白屏。

这三步做完，你手里的scheme清单才算真正可用。我见过太多人网上复制一段alipays://就说接好了，结果线上反馈「点了没反应」，一查是旧版本App不认新参数。验证这件事上没有捷径，adb拉起一次的成本不到十秒，别省。

3. 已开放的支付宝scheme整理：按业务入口逐个拆

3.1 两个稳定入口：蚂蚁森林与扫一扫

先说两个我反复验证过、跨版本基本不变的入口，也是日常高频需求。

蚂蚁森林的scheme是alipays://platformapi/startapp?appId=20000056。这个appId是支付宝客户端内部业务的固定标识，我这两年测过的Android和iOS版本都还能用。跳过去直接落在森林首页，用户能从能量球列表看到今天的可收能量。做活动页的时候，常见的做法是给它拼一个来源参数，比如chInfo=activity，用于区分流量从哪个页面进来。但是要注意，chInfo这类参数不是所有版本都认，不认的时候会被忽略，不影响跳转，只影响你在后台的渠道归因。

扫一扫入口则用alipays://platformapi/startapp?saId=10000007。注意这里参数名是saId，和蚂蚁森林的appId不是一个体系。saId是支付宝早期的服务号体系标识，现在虽然服务号功能淡出，但扫一扫作为公共能力还留着这个入口。这两个的区别可以粗略理解为：appId走新版业务路由，saId走旧版能力路由，二者无法互换。

我一般给客户的建议是：运营位跳蚂蚁森林，工具类跳扫一扫，付款码单独走支付链路。原因很简单，蚂蚁森林是留存场景，扫一扫是线下连接场景，用户目的完全不同。

3.2 生活服务类：账单、卡包与城市服务

账单、卡包、城市服务这类入口，开放情况比前两个复杂，不同版本差异明显。以账单为例，抓包常见的形式是alipays://platformapi/startapp?appId=20000067，跳过去是资金明细页。这个appId我在多个版本里验证过，基本可用，但跳过去默认展示的是「全部账单」，如果你想切到某个分类，比如只显示餐饮消费，需要额外带参数。

卡包入口相对收敛，通常落在alipays://platformapi/startapp?appId=20000070这类格式上。值得注意的是，卡包内部有优惠券、会员卡、票证等多个tab，scheme只会打开卡包首页，无法直接定位到某个券。如果你运营的是券类活动，建议把用户引导到H5领券页，再让用户自己进卡包查看，而不是试图用scheme做深度直达。

城市服务也是类似局面。它的入口是动态配置的，不同城市的服务列表完全不一样，scheme只能打开城市服务首页，首页内容由LBS定位决定。这意味着你在测试环境验证通过，不代表生产环境用户也能看到同一屏内容。这类「位置相关」的scheme，我的建议是接之前先想清兜底文案：如果服务列表里没有目标服务，用户等于跳了个寂寞。

3.3 支付链路类：付款码与转账的区别

支付链路是跳转需求里对准确性最敏感的，因为牵扯钱，跳错一步用户就可能会投诉。

付款码的scheme常见格式是alipays://platformapi/startapp?appId=20000056这类带payCode标识的路由，但这里我不给你列死参数，原因是付款码的入口在不同版本里做过多次调整，有的版本用appId，有的版本已经切换到saId=20000045。你需要用第2章的抓包方法，在自己要支持的最老版本App上走一遍「我的-付款码」，记录当时的真实请求。

转账入口则相对统一，通常是alipays://platformapi/startapp?appId=20000016之类，拉起后进入转账首页，由用户自己选最近联系人或者输入账号。这里有个安全细节：不要尝试在scheme里直接拼对方账号实现「一键转账」，支付宝对这类敏感动作有独立的二次校验，scheme传参也覆盖不到，网上流传的「带收款方参数直转」基本都失效了。

3.4 参数路由规则：saId、appId、params到底谁说了算

理解scheme的参数优先级，比背100个appId更有用。alipays://platformapi/startapp是支付宝的统一路由入口，后续参数决定打开哪个子功能。我拆过的协议里，路由判断顺序大致是：先看有没有saId，有则走旧版路由；没有就找appId，找到则走新版路由；二者都缺则直接回落到支付宝首页。params里的键值对是传给目标业务的，是否生效完全看目标业务读不读，读哪些键，键盘上没有任何公开约定。

常见的params键包括url（兜底H5链接）、chInfo（渠道标记）、from（来源页面）、extInfo（扩展信息）。我见过有人把运营活动的大段JSON塞进params，结果Android上跳转成功但iOS上被截断，原因是URL scheme的长度在系统层有隐式限制。所以我的原则是：params里只放短字符串键值，复杂数据全部放H5端用localStorage或URL hash传递。

这张表的用途是帮你排优先级：稳定性高的入口放心用，稳定性低的入口要么做降级、要么在发版前用adb回归一遍。

4. 避坑：五个踩过的alipays跳转坑位

4.1 昨天还能跳，今天彻底没反应

现象：前一天联调还好好的，第二天测试反馈点击按钮无反应，adb拉起也是黑屏或直接回桌面。

原因：支付宝客户端会在服务端下发路由配置，某些入口在灰度期开放、全量期关闭，或者你的测试账号被划出了白名单。更隐蔽的一种是App热更新把appId对应的内部组件下线了，scheme还在但目标页面已移除。

解决：先看手机支付宝是否自动更新了版本；再用当前版本重新抓一次目标功能的请求，对比appId是否变化；最后用adb拉起看报错是ActivityNotFound还是SecurityException，前者是路由没了，后者是签名校验没过。线上环境建议给跳转按钮加H5兜底链接，scheme失败时提示用户手动打开支付宝搜索对应功能。

4.2 带了城市参数跳过去却是首页

现象：我在某城市服务scheme上拼了定位参数，结果跳过去永远是首页，完全没有进入服务列表。

原因：城市服务的城市编码不是通过scheme参数传入的，而是客户端启动时根据GPS和SIM卡位置自己拿的。你试图传的cityCode键压根不在目标业务的读取白名单里，自然被忽略。

解决：放弃在scheme里传城市参数的念头，改用跳转后引导用户手动选择城市。如果你做的是区域运营活动，建议给出不同城市的H5落地页地址，让scheme的url参数直接指向对应的H5，再在H5里引导打开支付宝。这样既保证跳转成功率，又保留了城市差异。

4.3 iOS上scheme被另一个App抢注

现象：同样一个alipays://链接，Android上正常进支付宝，iOS上却弹出了别的App或者跳到App Store。

原因：iOS的scheme注册机制是全局的，任何App都能声明自己处理alipays，如果用户手机里某App的CFBundleURLSchemes里也写了alipays，系统会优先把这个scheme派发给后安装的那个App。这是个老问题，官方修复遥遥无期。

解决：在iOS侧不要直接用location.href = "alipays://..."，先调canOpenURL判断当前scheme是否能被支付宝响应，并且在Info.plist的LSApplicationQueriesSchemes里只声明alipays这一个标识，减小与其他App冲突的面。更稳的方案是改用Universal Link，让系统在scheme不可信时自动走HTTPS链路分发到支付宝。

4.4 浏览器打开scheme回跳失败白屏

现象：用户在电脑上用浏览器打开H5页面，点击跳支付宝按钮毫无反应，手机上浏览器打开倒是能跳，但跳完点返回按钮回不到原页面。

原因：电脑端没有支付宝App，scheme天然无法解析；手机端浏览器跳scheme后，原页面被切到后台，支付宝处理完通过回跳链接回到H5，但回跳URL恰好不在你允许的域名白名单里，被H5框架拦掉了。

解决：在HTML里用JS先做平台判断，非手机端直接引导用户扫二维码；手机端跳转前记录来源URL，支付宝回跳后比对document.referrer是否存在于你预设的域名列表，不在则提示重新进入活动页，而不是让用户停在白屏页焦虑。

4.5 反编译出一堆alipays，九成以上不能用

现象：从APK里提取到几百个带alipays的scheme，兴奋地一个个拉着试，结果大部分要么闪退、要么无响应。

原因：客户端Manifest里注册的scheme分两类：一类是对外可调起的公共入口，放在platformapi/startapp路由下；另一类是内部组件间通信用的私有路由，带签名校验或ACL限制，外部调用直接被拒绝。反编译只能看到注册声明，看不到运行时的权限判断。

解决：把反编译结果只当候选池，先用抓包确认哪些入口是真实对外暴露的，再按业务优先级挑5个核心入口做adb回归，验证通过才算数。我给自己定了个规矩：每个大版本更新后，跑一遍核心入口的冒烟脚本，凡是连续两次验证失败的scheme直接从清单里删掉，不给线上埋雷。

5. 从scheme看安全边界：开放与风险是对称的

5.1 攻击者视角：scheme劫持为什么长期存在

讨论scheme安全不是教人去攻击，而是让接方知道风险从哪来。支付宝scheme开放是给业务导流用的，但它本质上是系统级的URL派发，凡是系统级派发就有被抢占的可能。

Android端的问题出在Intent匹配的模糊性。如果设备上同时有两个App都声明了alipays的scheme，系统弹窗让用户选谁处理，攻击者可以伪造一个同scheme的恶意App等用户点错。iOS端更直接，后安装的App可以覆盖先安装App的scheme声明，用户手机上有个恶意App注册了alipays，那所有跳转请求都会先进恶意App手里，它可以展示钓鱼页面再转发给真正的支付宝。很多用户就在这一步里被钓走了支付密码。

这类攻击没法彻底消除，因为scheme的注册权在系统侧。你能做的防御，是在业务层面对跳转结果保持怀疑：不要相信「scheme已经跳转」就等于「用户到了支付宝」，中间可能隔了一层恶意转发。

5.2 开发者视角：消费scheme时的三条防御习惯

第一，不在WebView里裸调scheme。WebView页面被注入脚本后，攻击者可以篡改跳转URL指向恶意scheme，所以每次跳转前应该用原生层校验URL前缀必须是alipays://platformapi/startapp，其他host一律拒绝。

第二，跳转后要做回来校验。支付宝处理完业务会回跳到你指定的URL，回跳URL里带上一次性token，这个token只能由你的后端在跳转前生成、在回跳时验证，如果验证失败说明跳转链路被劫持过，应该终止后续流程。

第三，不在跳转参数里携带敏感信息。scheme的query部分会暴露在系统日志、浏览器历史、抓包工具里，任何人可见。凡是跟用户身份、订单金额、账号相关的信息，一律放到你自己的H5页面上，通过后端会话关联，而不是塞进params裸奔。

5.3 平台视角：白名单与签名校验才是安全本体

支付宝侧也不是什么都没做。platformapi/startapp路由对appId和saId都有合法性校验，非法值直接拒绝。对于涉及资金变动的入口，还会额外校验调用方的来源包名和签名，只有签名匹配的调用者才能拉起完整功能。这解释了为什么网上有些旧scheme在旧版本能用、新版本失效——不是支付宝关了入口，而是签名校验范围扩大了。

理解这一层之后，你对接scheme的心态就稳了：它永远不可能是一个100%开放的跳转黑匣子，而是在平台安全策略约束下的有限开放。做技术方案的时候，不要把全部希望押在一个scheme上，设计成scheme为主、H5兜底、必要时引导用户手动搜索的三级链路，才是对抗版本波动和平台风控的成熟姿势。

6. 落地：把scheme清单变成你自己的跳转工具

方案做得再细，不如手里有个自更新的清单生成器。我最后留一个可以直接跑的Python脚本，它读取支付宝APK的Manifest信息，把注册了alipays的scheme全部导出，你再回到真机上按第2章方法验证。上面没写到的入口，用它会持续补全。

# 依靠androguard解析apk中的AndroidManifest.xml，提取alipays相关scheme from androguard.core.bytecodes.apk import APK def extract_alipays_schemes(apk_path): apk = APK(apk_path) schemes = set() # package是包名，activities保存所有声明的Activity节点 for activity in apk.get_activities(): # 这里只关心支付宝自身包名，避免混入其他应用 if "alipay" not in apk.get_package(): continue # 每个Activity可能声明多个intent-filter，逐个解析 for intent in activity.get_intent_filters(): for scheme in intent.get_schemes(): if scheme == "alipays": # 把发现scheme的Activity名字一并记录，方便回查路由 schemes.add((activity.get_name(), scheme)) return sorted(schemes) if __name__ == "__main__": # 替换成你下载的支付宝APK本地路径 result = extract_alipays_schemes("./alipay_android.apk") for activity, scheme in result: print(f"{activity} -> {scheme}")

运行时先装依赖：pip install androguard，然后把脚本里的APK路径换成你从应用市场拉下来的包。脚本会把所有声明了alipays的Activity和对应的scheme打印出来，输出结果就是你的原始候选池。要注意，这个脚本只完成「提取」，不判断「是否可用」，所以拿到结果后必须回到adb验证环节，否则你只是把静态声明当成了真相。

我用这套流程维持自己的scheme清单快两年了，最大的教训是：一切以当前线上的真实抓包为准，网上所有号称大全的清单，都只是某个时间点的快照，App一更新快照就过时。从那以后，我每次接到跳转需求，都强制自己先跑一遍提取脚本，再用adb拉起三个核心入口，确认无误才敢写联调文档。这份功夫不会白费，至少「昨天还能跳今天不行」的求助，我再也没收到过。希望帮到你。

本文还有配套的精品资源，点击获取