简介面向移动端开发者和经常需要快速唤起支付宝特定页面的用户资源整理了从支付宝 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?saId10000007执行完第三行命令后正常情况下测试机应该直接弹出支付宝的「扫一扫」页面。这个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 21 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?appId20000056url${encodeURIComponent(bizQuery)}; console.log(finalUrl); // 实际输出示例alipay://platformapi/startapp?appId20000056urluserId%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?appId20000056 # 观察日志输出中是否出现 HandleScheme 或 RejectScheme 关键字如果日志里出现RejectScheme说明支付宝收到了这个 scheme 但拒绝了通常是参数校验失败或业务已下线。如果连HandleScheme都没有说明 scheme 没有投递到支付宝的 Scheme Handler这时候要先检查是不是am start命令的格式问题。支付宝的 scheme 处理器日志标签在不同版本里不太一样我测试了几个版本后发现用AlipayScheme能覆盖绝大多数日志输出如果抓不到就退到grep -i alipay看全局日志。4. 蚂蚁森林专项scheme 参数实战与状态码语义4.1 蚂蚁森林深链的 URL 结构拆解蚂蚁森林是自动化测试里非常典型的目标场景因为它内部有多个子页面主森林、好友森林、排行榜、浇水记录。网上能找到的蚂蚁森林 scheme 大多只有一个主页面入口进阶子页面很少有人整理。这份资源里给出的蚂蚁森林深链结构大致长这样alipay://platformapi/startapp?appId60000023url%2Fwww%2Fantforest%2Findex.html%3FuserId%3Dxxxx拆开看appId60000023是蚂蚁森林在支付宝内的应用标识真正关键的是url参数里的内容——它是一个相对路径指向蚂蚁森林的 H5 页面入口。url参数的值做了 URL 编码解码后是/www/antforest/index.html?userIdxxxx。注意这里的userId不是你登录支付宝的账号 ID而是目标用户在当前场景下的业务 ID如果传错人的 ID页面能打开但不是你要看的那个森林。资源里把这类「业务页面路径」形式的 scheme 单独归类并在参数表里标注了 userId 的获取方式通常有两个途径一个是调用支付宝开放平台的用户信息接口拿到的user_id字段另一个是从蚂蚁森林页面分享链接的 query 里解析。前者适合服务端拼接后者适合客户端做断点调试。4.2 参数表必填、选填与「填了反而报错」的字段蚂蚁森林 scheme 的参数表是这份资源里含金量最高的部分。整理如下参数名类型必填说明常见错误appIdString是蚂蚁森林业务标识固定为 60000023传成支付宝 App 的 AppIDurlString是编码后的业务路径含页面路由和 query忘记二次编码导致 截断userIdString否目标用户业务 ID不传则打开自己的森林误传成支付宝账号sourceString否来源标记用于统计自定义字符串不影响功能referString否渠道来源部分旧版本不识别可省略这里面最坑的是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?appId60000023url${encodeURIComponent(fullPath)};这段代码的要点是URLSearchParams会自动处理 userId 里的特殊字符encodeURIComponent只包住完整路径。如果你把routePath也放进URLSearchParams斜杠会被编码成%2F支付宝的解析器大概率不认这种形式。4.3 返回状态码0、1、-1 背后对应的真实含义蚂蚁森林 scheme 执行后的返回状态不像普通 HTTP 请求那样有清晰的 200/404而是在日志或回调里体现为简单的数字状态码。资源里对不同状态码做了对照说明三个最常见0scheme 被解析且页面成功拉起这是理想状态。1scheme 被解析但目标页面初始化失败一般是内部接口超时或路由参数不匹配页面会闪退或白屏。-1scheme 被拒绝通常是 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 fadb -s {device_id} shell am start -a android.intent.action.VIEW -d \{scheme}\ subprocess.run(cmd, shellTrue, checkFalse) time.sleep(3) focus_cmd fadb -s {device_id} shell dumpsys window | grep mCurrentFocus result subprocess.run(focus_cmd, shellTrue, capture_outputTrue, textTrue) return result.stdout.strip() def run_regression(config_path): 读取 scheme 配置并逐条验证 with open(config_path, r, encodingutf-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(fFAILED: {f[name]} - {f[actual]})这段脚本的坑点在于expected_focus要怎么写支付宝的 Activity 名称在 Debug 和 Release 包下可能不一致直接写类名容易误报。我一般会先手动拉起一次目标页面用dumpsys window抓真实字符串再把它作为期望值写进配置。脚本跑完后失效的 scheme 会输出到失败列表我每周花十分钟看一眼结果新增的失效条目就从配置里摘除换来的是线上深链跳转的成功率稳定在九成以上。这也让我养成了一个习惯每季度强制把这份资源重新翻一遍对照支付宝新版本特性去刷新配置而不是等到线上用户反馈跳转失败才去排查。希望这份拆解能帮你把支付宝 scheme 从玄学变成可维护的工具链少走我踩过的那些弯路。本文还有配套的精品资源点击获取