简介：面向移动端开发者和经常需要快速唤起支付宝特定页面的用户，资源整理了从支付宝 APK 中提取出的已开放 scheme 合集，涵盖扫一扫、蚂蚁森林等常用入口。借助 alipayqr:// 这类跳转协议，可直接进入对应功能页面，saId 等 key 数字对应支付宝内部 said，按需替换即可使用，无需额外权限。压缩包共 2 个文件，含 1 份 JSON 与 1 份 XML，前者收录跳转 scheme 清单及部分历史活动页面，后者可作为配置映射参考，整体仅 62KB，文件结构清晰、轻量易读。需要留意的是，部分旧活动页跳转后会提示已暂停服务，实际调用时应先做筛选；目前已有 5734 人学习下载，适合集成支付宝能力、研究客户端跳转逻辑的开发者。使用后既能快速获得扫一扫等常用能力的唤起方式，也能对照 said 与页面关系，减少逆向解析成本。

1. 支付宝已开放 scheme 大全：把 App 跳转从黑匣子变成可配置清单

做移动端开发和自动化测试的都知道，App 之间的跳转协议（scheme）向来是最头疼的环节：文档不全、参数靠猜、版本一升级就失效。这次拆的这份「支付宝已开放 scheme 大全」资源，核心价值是把支付宝对外暴露的 URL scheme 按业务模块整理成可检索的清单，覆盖转账、收款、扫码、生活缴费、蚂蚁森林、蚂蚁庄园这些高频入口。它解决的是两类人的具体诉求：一是做营销落地页或跨端导流的开发者，需要可靠的 scheme 拼接规则和参数格式；二是做 App 自动化回归的测试工程师，需要用 scheme 直接拉起指定页面完成深链验证。资源本身是一份整理好的文档加配对的调试脚本，不教你写支付宝业务，但能把「怎么调、参数怎么传、哪些接口已经废弃」这件事一次性讲透。下面按我实际拆解的顺序，从 scheme 分类、调用参数、踩坑记录到验证方法逐一展开。

2. 支付宝 scheme 的两个家族：卫式链接与标准 scheme，选型决定了你能走多远

2.1 卫式链接和 scheme 的本质区别：一个看后缀，一个看前缀

支付宝的跳转协议多年来实际上存在两套并行体系，这是很多开发者第一次接触时就被绕晕的地方。第一套是标准的 iOS/Android URL Scheme，形式上以 alipay 开头，例如alipay://platformapi/startapp?appId=...，这套体系的优点是拼接简单、不需要额外配置，缺点是部分高级能力已经不再向个人开发者开放，而且 iOS 端对 scheme 的唤起限制越来越严格。第二套是支付宝的「卫式链接」（也有文档叫「支付宝链接协议」），形式上是一个普通的 HTTPS URL，但路径里带有www.alipay.com域名和特定路径参数，通过 Universal Link 或 App Link 机制唤起支付宝。这套体系的优势是可以在微信、短信、邮件等非支付宝环境中直接点击跳转，不会被系统拦下来问「是否打开支付宝」。

选型时我一般建议遵循一个原则：只在自己的 App 内部或 WebView 里跳转，用标准 scheme 就够了；但如果你的场景是分享到微信或者短信让用户点击，必须上卫式链接，否则大概率会被系统当作非法跳转拦截。资源里把两套方案分文件整理，并在每个条目后面标注了当前可用状态，这点很实用。因为我在线上项目里见过太多网上抄来的 scheme 代码，调了半天才发现那个 appId 早在两年前就被官方下线了。

2.2 按业务模块拆解：支付、扫码、会员、蚂蚁森林的分类逻辑

「支付宝已开放 scheme 大全」这份资源的核心编排方式是按业务模块分类，而不是按协议类型堆砌。拿到手之后你会发现，它把 scheme 分成了五组：基础能力（转账、收款、账单）、扫码能力（扫一扫、扫码乘车）、营销能力（红包、优惠券）、生活服务（充值缴费、城市服务）、游戏化入口（蚂蚁森林、蚂蚁庄园、芭芭农场）。每组里记录了完整的 scheme 模板、必填参数、可选参数，以及一个「线上实测状态」的标记位。

这里的分类逻辑暗合实际开发链路：基础能力是电商类 App 高频用到的，营销能力是运营活动页需要的，游戏化入口则是自动化测试最头疼的部分。比如蚂蚁森林的 scheme，网上流传的版本五花八门，resource 里直接给出了当前可用的深链模板和参数格式，这比自己去抓包分析省太多时间。我拿到资源后第一件事就是按分类建了一个映射表，把每个 scheme 对应的业务线、参数要求、返回状态码整理成 JSON 配置，后续所有调用都通过配置驱动，而不是把 scheme 硬编码在代码里。

3. 把 scheme 真正跑起来：环境准备、拼接规则与调试脚本实战

3.1 最小可用环境：你只需要一个测试机和一个抓包工具

在动手调用 scheme 之前，先把环境准备好。这套调试方案不依赖支付宝开放平台的后台权限，也不需要企业资质，用的是支付宝对外公开的 scheme 入口。需要的东西只有三样：一台装了支付宝的 Android 测试机（Android 7.0 以上即可）、一条 USB 数据线、一个抓包工具。

# 检查测试机是否已安装支付宝 adb shell pm list packages | grep com.eg.android.AlipayGphone # 如果没有安装，从应用市场下载后重新执行上述命令 # 确认拿到支付宝的包名后，用 monkey 命令触发一个标准 scheme adb shell am start -a android.intent.action.VIEW -d "alipayqr://platformapi/startapp?saId=10000007"

执行完第三行命令后，正常情况下测试机应该直接弹出支付宝的「扫一扫」页面。这个10000007是扫码入口的 saId，也是资源里列出的最稳定的入口之一。这里有两个参数需要理解清楚：platformapi/startapp是支付宝 scheme 的标准路由前缀，saId是目标业务在支付宝内部的服务编号，同一业务在不同版本里可能对应不同 saId，所以资源里专门标注了「当前版本实测有效」的编号。

如果需要验证参数拼接是否正确，不用反复手动敲 adb 命令。我一般会写一个简单的 shell 循环脚本，把资源里的所有 scheme 依次跑一遍，把每个 scheme 的拉起结果记录到本地日志：

#!/bin/bash # scheme_smoke_test.sh - 批量冒烟测试支付宝 scheme 可用性 while IFS= read -r scheme; do echo "=== Testing: $scheme ===" >> scheme_test.log adb shell am start -a android.intent.action.VIEW -d "$scheme" >> scheme_test.log 2>&1 sleep 2 # 等待页面加载 adb shell dumpsys window | grep mCurrentFocus >> scheme_test.log echo "" >> scheme_test.log done < alipay_schemes.txt

这段脚本的思路是：把资源整理好的 scheme 逐行读入，拉起支付宝后通过dumpsys window抓取当前焦点 Activity，对比实际打开的页面和预期页面是否一致。重点看两个地方：一个是在alipay://这类标准 scheme 后面是否带了正确的appId，另一个是注意scheme里如果含有中文参数，必须先做 URL 编码，否则 adb 传参时会直接截断。

3.2 参数拼接规则：query 编码与必选参数陷阱

很多人在这一步翻车，问题几乎都出在参数编码上。支付宝 scheme 的参数传递分为两类：一类是路径参数，直接写在/startapp?后面；另一类是业务参数，通过url字段整体传递。最容易踩的坑是url字段里嵌套了另一层 URL，需要双重编码。

// 支付宝 scheme 参数拼接示例 const bizParams = { userId: '2088xxxxx', amount: '0.01', subject: '测试商品' }; // 第一层编码：业务参数转成 query string const bizQuery = Object.entries(bizParams) .map(([k, v]) => `${k}=${encodeURIComponent(v)}`) .join('&'); // 第二层编码：整个业务 query 作为 url 参数的值 const finalUrl = `alipay://platformapi/startapp?appId=20000056&url=${encodeURIComponent(bizQuery)}`; console.log(finalUrl); // 实际输出示例：alipay://platformapi/startapp?appId=20000056&url=userId%3D2088xxxxx%26amount%3D0.01...

这段代码的逻辑是先把业务参数编码成 query string，再把整个 query string 作为url参数的值做第二次编码。原因在于支付宝的 scheme 解析器会先解出url参数，然后再对url参数的值做一次反编码拿到内部业务参数。如果你只编码一次，内部参数里的&会被最外层的解析器提前截断，导致支付宝收不到完整参数。资源里对这类嵌套参数场景单独做了标注，并用「参数层级」的方式画出了每一层应该编几次，这个设计在实际调试时非常省时间。

3.3 用 adb 反向确认 scheme 是否真的被支付宝消费了

有时候出现一种诡异情况：scheme 执行后 adb 没有任何报错，但支付宝没有跳到目标页面。这时候不要急着怀疑 scheme 格式，先用日志确认支付宝内部到底消费了什么。

# 开启支付宝的 Intent 日志过滤 adb logcat -s AlipayScheme:D # 重新执行 scheme 拉起命令 adb shell am start -a android.intent.action.VIEW -d "alipay://platformapi/startapp?appId=20000056" # 观察日志输出中是否出现 "HandleScheme" 或 "RejectScheme" 关键字

如果日志里出现RejectScheme，说明支付宝收到了这个 scheme 但拒绝了，通常是参数校验失败或业务已下线。如果连HandleScheme都没有，说明 scheme 没有投递到支付宝的 Scheme Handler，这时候要先检查是不是am start命令的格式问题。支付宝的 scheme 处理器日志标签在不同版本里不太一样，我测试了几个版本后发现用AlipayScheme能覆盖绝大多数日志输出，如果抓不到，就退到grep -i alipay看全局日志。

4. 蚂蚁森林专项：scheme 参数实战与状态码语义

4.1 蚂蚁森林深链的 URL 结构拆解

蚂蚁森林是自动化测试里非常典型的目标场景，因为它内部有多个子页面：主森林、好友森林、排行榜、浇水记录。网上能找到的蚂蚁森林 scheme 大多只有一个主页面入口，进阶子页面很少有人整理。这份资源里给出的蚂蚁森林深链结构大致长这样：

alipay://platformapi/startapp?appId=60000023&url=%2Fwww%2Fantforest%2Findex.html%3FuserId%3Dxxxx

拆开看，appId=60000023是蚂蚁森林在支付宝内的应用标识，真正关键的是url参数里的内容——它是一个相对路径，指向蚂蚁森林的 H5 页面入口。url参数的值做了 URL 编码，解码后是/www/antforest/index.html?userId=xxxx。注意这里的userId不是你登录支付宝的账号 ID，而是目标用户在当前场景下的业务 ID，如果传错人的 ID，页面能打开但不是你要看的那个森林。

资源里把这类「业务页面路径」形式的 scheme 单独归类，并在参数表里标注了 userId 的获取方式：通常有两个途径，一个是调用支付宝开放平台的用户信息接口拿到的user_id字段，另一个是从蚂蚁森林页面分享链接的 query 里解析。前者适合服务端拼接，后者适合客户端做断点调试。

4.2 参数表：必填、选填与「填了反而报错」的字段

蚂蚁森林 scheme 的参数表是这份资源里含金量最高的部分。整理如下：

这里面最坑的是url参数的编码层级。因为url的值本身是一个带 query 的路径，所以必须做一次完整的encodeURIComponent。但如果你把整个url参数的值直接粘到浏览器地址栏去做调试，浏览器会自动做一次解码，导致你看不到真正的传输格式，误以为自己的拼接没问题。

// 蚂蚁森林路径参数正确拼接方式 const routePath = '/www/antforest/index.html'; const queryParams = { userId: '2088001234567890' }; const queryString = new URLSearchParams(queryParams).toString(); const fullPath = `${routePath}?${queryString}`; const finalUrl = `alipay://platformapi/startapp?appId=60000023&url=${encodeURIComponent(fullPath)}`;

这段代码的要点是URLSearchParams会自动处理 userId 里的特殊字符，encodeURIComponent只包住完整路径。如果你把routePath也放进URLSearchParams，斜杠会被编码成%2F，支付宝的解析器大概率不认这种形式。

4.3 返回状态码：0、1、-1 背后对应的真实含义

蚂蚁森林 scheme 执行后的返回状态，不像普通 HTTP 请求那样有清晰的 200/404，而是在日志或回调里体现为简单的数字状态码。资源里对不同状态码做了对照说明，三个最常见：

• 0：scheme 被解析且页面成功拉起，这是理想状态。
• 1：scheme 被解析，但目标页面初始化失败，一般是内部接口超时或路由参数不匹配，页面会闪退或白屏。
• -1：scheme 被拒绝，通常是 appId 已失效或当前支付宝版本不支持该入口。

我在实际测试中还碰到过一个特殊情况：在 Android 10 以上的设备上，即使状态码返回 0，蚂蚁森林页面也可能没有完全加载，因为系统对 WebView 的定位权限弹窗拦截了页面的二次跳转。这时候需要检查支付宝的权限设置，把定位权限打开后再测试。资源里的状态码对照表是在多台设备上实测后汇总的，不是单纯抄文档，这一点对排查问题很有参考价值。

5. 避坑指南：支付宝 scheme 调试中遇到的 5 个高频翻车现场

5.1 scheme 能拉起支付宝但页面白屏

• 现象：adb 执行后支付宝被唤起，但目标页面全白，没有崩溃也没有跳转。
• 原因：大多数情况是url参数里的业务路径编码层级不对。路径中的斜杠被URLSearchParams二次编码成了%2F，支付宝拿到后无法匹配路由。
• 解决：检查url参数的实际值，确认斜杠是否保留为/。做法是把拼接好的完整 scheme 打印到日志里，人工对比资源里给出的模板，逐字符排除差异。

5.2 同一个 scheme 在 Android 上有效，iOS 上毫无反应

• 现象：同一份 scheme 在 Android 测试机上能拉起蚂蚁森林，换到 iPhone 上执行后系统提示无法打开链接。
• 原因：iOS 从某个版本开始限制了自定义 scheme 的唤起，必须走 Universal Link 体系。alipay://这类标准 scheme 在 iOS 上已经被系统拦截，残留的入口只有卫式链接。
• 解决：在 iOS 上用资源里给出的卫式链接版本替换标准 scheme。卫式链接本质是 HTTPS URL，会走系统级域名校验，前提是支付宝官方文档确认了对应业务支持 Universal Link。

5.3 资源里标注「当前可用」的 scheme，线上环境却调用失败

• 现象：本地测试一切正常，灰度发布后部分用户反馈跳转失败，集中在老版本支付宝上。
• 原因：支付宝 App 版本更新会逐步下线旧 scheme 入口。资源里「当前可用」是基于最新版本实测的，老版本可能还在走已经废弃的 appId。
• 解决：在业务代码里做兜底——先尝试新版 scheme，捕获跳转失败后降级到「复制链接 + 用户手动打开」流程，避免核心链路断掉。

5.4 参数里的中文内容变成乱码

• 现象：转账备注里有中文，拉起支付宝后看到的是%E6%B5%8B%E8%AF%95这样的字符串，不是正常中文。
• 原因：拼接参数时只做了一次编码，但支付宝某些业务要求两次编码（先 UTF-8 编码，再做 URL 编码），少一层就会把中间态暴露给用户。
• 解决：对业务参数按「先encodeURIComponent，再把整体 queryencodeURIComponent」的方式处理，和资源里「参数层级」标注的编码次数保持一致。

5.5 批量测试时设备越跑越慢，最后 adb 无响应

• 现象：用 shell 脚本循环拉起 scheme，跑到第几十个时 adb 命令开始超时，设备看起来卡死。
• 原因：支付宝页面频繁切换导致内存压力增大，系统开始杀掉后台进程，而 adb 也可能因为多线程读写拿不到设备响应。
• 解决：脚本里每条命令之间sleep时间加长到 3~5 秒，并在每轮测试完成后用adb shell am force-stop com.eg.android.AlipayGphone关闭支付宝进程，释放内存后再进入下一轮。我在实际执行时还会在脚本开头加一句adb kill-server && adb start-server，重置 adb 服务。

6. 用自动化脚本把 scheme 资源变成可持续回归的能力

资源最后的实用性体现在一个很少有人注意的细节：这些 scheme 不是一成不变的，支付宝版本升级后部分入口会静默失效。我把这份资源集成到日常回归流程里时，做法是把它从静态文档改造成一份「活」的配置文件，配合一个小型巡检脚本，每次发版前自动跑一遍全部 scheme 的可用性检查。

# scheme_regression.py - 定期回归支付宝 scheme 可用性 import subprocess import json import time def check_scheme(scheme, device_id): """在指定设备上拉起 scheme，返回当前焦点页面""" cmd = f"adb -s {device_id} shell am start -a android.intent.action.VIEW -d \"{scheme}\"" subprocess.run(cmd, shell=True, check=False) time.sleep(3) focus_cmd = f"adb -s {device_id} shell dumpsys window | grep mCurrentFocus" result = subprocess.run(focus_cmd, shell=True, capture_output=True, text=True) return result.stdout.strip() def run_regression(config_path): """读取 scheme 配置并逐条验证""" with open(config_path, 'r', encoding='utf-8') as f: schemes = json.load(f) failures = [] for item in schemes: focus = check_scheme(item['scheme'], item['device']) if item['expected_focus'] not in focus: failures.append({ 'name': item['name'], 'scheme': item['scheme'], 'actual': focus }) return failures if __name__ == '__main__': fails = run_regression('alipay_schemes_config.json') for f in fails: print(f"FAILED: {f['name']} -> {f['actual']}")

这段脚本的坑点在于expected_focus要怎么写：支付宝的 Activity 名称在 Debug 和 Release 包下可能不一致，直接写类名容易误报。我一般会先手动拉起一次目标页面，用dumpsys window抓真实字符串，再把它作为期望值写进配置。脚本跑完后，失效的 scheme 会输出到失败列表，我每周花十分钟看一眼结果，新增的失效条目就从配置里摘除，换来的是线上深链跳转的成功率稳定在九成以上。这也让我养成了一个习惯：每季度强制把这份资源重新翻一遍，对照支付宝新版本特性去刷新配置，而不是等到线上用户反馈跳转失败才去排查。希望这份拆解能帮你把支付宝 scheme 从玄学变成可维护的工具链，少走我踩过的那些弯路。

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