App Store、Google Play 与 AppGallery 链接格式：参考手册
三大应用商店的全部规范、遗留与 scheme URL 形式：每种形式的作用、在哪里失效，以及悄悄吞掉活动数据的编码错误。写给你的收藏夹。
链接格式为什么会咬人
每个商店都为同一个应用页面维护至少三种 URL 形式：规范的 https URL、靠重定向续命的遗留形式，以及完全绕过浏览器的设备 scheme。它们看似可以互换。其实不能。scheme 在错误的操作系统上是死链，遗留形式依赖你无法控制的重定向，规范形式则藏着悄悄改变行为的选项——国家代码、referrer 参数。
本页用占位值把它们全部列出：每种形式的用途，以及各自在哪里失效。格式是常量，变的只是围绕它们的活动。
Apple App Store
一条规则理清所有 Apple 链接：解析以数字 id 为准。路径里的 {app-name} 只是装饰——拼错、换掉、删掉都行，只要 id{appId} 完好，链接就落在同一个页面上。
https://apps.apple.com/{country}/app/{app-name}/id{appId}https://apps.apple.com/app/id{appId}https://itunes.apple.com/app/id{appId}itms-apps://itunes.apple.com/app/id{appId}- 国家代码是两位小写字母（us、cn、de）。它把链接锁定到单一店面——注册在其他国家的账户会看到可用性错误，即使应用在其本国商店已上架。
- 省略国家段，Apple 会根据访问者解析店面。对任何全球性场景，这是正确的默认做法，不是退路。
- 遗留的 itunes.apple.com URL 仍会重定向到 apps.apple.com。旧链接继续可用；不要再新建这种格式。
- itms-apps:// 直接打开 App Store 应用，跳过浏览器一跳。在 iOS 上省去一次可见的重定向；在 Android 或桌面上是死链。只在你能控制平台的地方使用。
Google Play
Play 的解析以包名——id 参数——为准。没有国家段；Play 按登录账户选择店面。有意思的工作都由可选参数完成。
https://play.google.com/store/apps/details?id={package}https://play.google.com/store/apps/details?id={package}&hl={lang}https://play.google.com/store/apps/details?id={package}&referrer=utm_source%3Dqr%26utm_campaign%3Dlaunchmarket://details?id={package}- &hl={lang} 会无视设备设置强制页面语言。给文档截图有用；在营销活动里几乎总是错的——不要加，让设备自己决定。
- market:// 直接打开 Play 应用，不经浏览器。仅限 Android；其他任何地方都是死链。
referrer 参数：多数团队忘掉的免费归因通道
放进 &referrer= 的内容会随安装一路传递，在首次启动时由 Play Install Referrer API 交给你的应用。这是不装归因 SDK 的安装归因：给一张二维码海报打上 utm_source%3Dqr%26utm_campaign%3Dlaunch，应用就知道是哪张海报带来了这次安装。
整个值必须做 URL 编码：= 变成 %3D，& 变成 %26。不编码的话，referrer 字符串里的第一个 & 就会终止参数——Play 悄悄保留 utm_source、丢掉后面的一切，而数据损失要等几周后才在报表里显形。
华为 AppGallery
AppGallery 在没有 Google 服务的地方举足轻重：出厂不带 Play 的华为与荣耀设备。应用 id 是带 C 前缀的数字，取自 AppGallery Connect 控制台。HMS 设备上存在 appmarket:// scheme——与所有 scheme 同一条警告：离开设备即死链。
https://appgallery.huawei.com/app/C{appId}appmarket://details?id={package}常见错误
五种失效模式几乎覆盖了流传在外的所有坏掉的商店链接。
在全球活动里强制国家代码
注册在其他店面的账户会遇到店面不符的错误。删掉这一段，让 Apple 按位置解析。
未编码的 referrer 值
裸的 & 会终止参数；Play 在第一组键值后悄悄截断。整个值都要编码：= 换成 %3D，& 换成 %26。
在邮件、二维码或社交简介里用 market:// 或 itms-apps://
scheme 只在自己的操作系统上解析——对其他人就是 404。任何跨平台表面都用 https，或者用按设备路由的链接。
用 http:// 而不是 https://
最好的情况多一次重定向；最坏的情况应用内浏览器出错、referrer 数据丢失。两个商店都是 https——就这么写。
链接到商店的搜索结果页
搜索 URL 的排序会变；今天的第一名明天未必是你的应用。链接到以 id 为准的规范页面。
2026：分发规则收紧，格式不变
按照 Google 的 Android 开发者公告，经验证开发者要求正在推开：2025 年 10 月起早期体验，2026 年 3 月全面开放，2026 年 9 月起在巴西、印度尼西亚、新加坡和泰国对 Play 之外安装的应用强制执行。这些都不改变上面的 URL 格式——改变的是谁可以在 Play 之外分发 Android 应用。指向 Play 页面的链接行为一如既往。
当一条链接必须通向所有商店
只面向单一平台时，手工拼这些格式完全够用。发给 iOS 用户的 iOS 通知，需要的只是一条规范的 Apple URL。
一旦单一表面要服务所有人——简介链接、印刷二维码、邮件页脚——矩阵就崩了。这时你需要给 iPhone 的 Apple URL、给多数 Android 的 Play URL、给华为设备的 AppGallery URL，再加一个桌面的网页回退，全都藏在一条链接后面。这个按设备路由的步骤正是智能链接做的事，也正是 Appy 免费套餐的用途：一个 URL，每台设备去自己的商店。
常见问题
App Store 链接该带国家代码吗？
只有当你确实只面向一个店面时才带——比如仅在美国商店有效的促销。其余情况一律省略，让 Apple 解析店面；锁死的代码对注册在别处的账户就是一个错误。
怎么给商店链接加活动数据？
Google Play：用 URL 编码后的 &referrer 参数，应用通过 Install Referrer API 读取。Apple：App Store URL 不为第三方携带活动参数——把 UTM 参数放在你控制的中间链接上，度量点击。AppGallery 没有等价的公开通道，同样采用中间链接的做法。
二维码需要特殊的商店链接格式吗？
不需要——二维码编码你给它的任何 URL。但它继承了单一操作系统的问题：编码了 Play URL 的二维码，对每一台扫它的 iPhone 都是死胡同。编码一条按设备路由的链接，而不是裸的商店 URL。
itms-apps:// 和 market:// 链接更快吗？
在对的设备上，是的——少一跳，直接进商店应用，没有浏览器闪现。离开设备就是死链。在平台有保证的地方用它们，比如你自己的 iOS 应用内部；受众混杂的地方一律用 https。
继续探索
不用 SDK 的延迟深度链接：底层到底是怎么运作的
不嵌入归因 SDK，也能把链接意图带过应用安装这道坎。本文讲清 Android 和 iOS 上什么能真正穿过商店边界、什么会断掉，以及每种变通方案的隐私代价。
延迟深度链接（deferred deep linking）：原理与使用时机
把原始链接意图带过安装环节，让新用户首次打开应用就直接进入对应页面，而不是默认首页。
2026 年移动归因：Privacy Sandbox 死后还有什么能用
Android Privacy Sandbox 已被取消，ATT 授权率仅约 14%，Safari 默认剥离 click ID。这是一份诚实的 2026 年归因地图：哪些测量机制仍然有效，以及应按什么顺序依赖它们。
想看更多内容？浏览 博客全部主题.