案例：客户「拜拜」如何用一张二维码做 iOS / 网页分流

「拜拜」是一款在线拜佛祈福 App（baifo.life），也是我们的客户。他们最近上线了两处扫码分享：「推荐给亲友」海报、拜佛记录分享海报。两张海报上都有一个二维码，需求很简单：扫码设备的是 iPhone，就跳转到 App Store 下载应用；扫码设备的是别的类型，暂无 App，就引导用户到网页版。

这是几乎所有做 App 推广的团队都会遇上的需求。下面既是他们的接入过程，也可以当成各位可能需要的教程。

为什么不自己写 UA 分流

最初他们想在 baifo.life 上自建 /get 路由：读请求头里的 User-Agent，用正则判断是不是 iOS，再 302 到对应目标。二维码固定指向这个地址。

这个方案可行，但是，这意味着他们需要搭建一套完整的基建：

分流规则——以后可能还要增加 Android 商店链接、不同地区链接不一样，都需要改代码、测试、重新部署
二维码统计功能——除了扫码之外，还需要点击统计、设备统计、等等细分
渠道来源——以后推广渠道越来越多，二维码需求量也比较大，难道完全自建一套系统么？维护起来太费力了

所以，拜拜团队决定将这些工作放到二维码短链接平台上，也就是我们。

教程：用 DYQR 做 OS 分流

下面按后台「新建链接」五步向导操作（配图均来自生产环境 app.dyqr.me 实机截图）。Smart Routing（含按操作系统分流）需要付费套餐；免费账号在第 2 步会看到 “Upgrade required”。若你更习惯终端，文末有 CLI / API 写法。

1. 创建短链，默认指向网页

打开控制台 → 新建链接，先填默认目标（所有未命中规则的流量都会落到这里）：

Title：例如「拜拜 App 下载」
Default destination：https://baifo.life/

创建短链：默认目标设为网页版

默认目标要选「大多数人该去的地方」——对拜拜来说，就是网页版。iOS 用户会在下一步用规则盖过它。

2. 添加 Smart Routing：OS = iOS → App Store

进入 Smart Routing 步骤，新增一条规则：

When：Operating system
Matches：iOS
Then go to：https://apps.apple.com/cn/app/id6782394476（换成你的 App Store 链接）

Smart Routing：操作系统条件选 iOS，跳转 App Store

要点：

条件类型选 Operating system（操作系统），不要用 Device（设备）——Device 只有 mobile / desktop，分不出 iPhone 和 Android 手机
规则启用后，iPhone（含微信内置浏览器）扫码会 302 到 App Store；其它流量仍走默认网页
以后要加 Android 商店、按国家换商店链接，只改规则，不用重新生成二维码，也不用发 App 版

3. 导出二维码，嵌进海报

向导最后一步预览并导出 QR。海报里只内嵌这张图（编码的是短链地址，不是最终落地页）：

导出二维码：短链固定，落地规则可改

App / 运营侧不用再维护分流逻辑，海报预览即所得。

4. 创建完成

保存后，链接会出现在 Links & QR codes 列表里，旁边自带二维码缩略图；标题、短链、默认目标一目了然。

创建完成后的链接列表（含二维码缩略图）

扫码时的实际分流：

iPhone（含微信内置浏览器）→ App Store（规则命中）
Android / 桌面浏览器 → baifo.life 网页（默认目标）
统计 → 每次扫码自动记入点击分析

可选：CLI / API 接入

如果团队更习惯终端或自动化，也可以不走 UI：

npx @dyqr/cli login
dyqr link create "https://baifo.life/" --title "拜拜 App 下载"
dyqr qr <alias> --format svg -o poster-qr.svg

配置 OS 规则（Bearer token 见后台 Account → Connected apps）：

curl -X PATCH https://app.dyqr.me/api/links/<alias> \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d '{
    "targetUrl": "https://baifo.life/",
    "routingRules": [{
      "id": "ios_app_store",
      "enabled": true,
      "targetUrl": "https://apps.apple.com/cn/app/id6782394476",
      "conditions": [{ "type": "os", "os": ["ios"] }]
    }]
  }'

这次真实接入反哺的产品能力

客户的真实需求通常总能准确命中我们的软肋。比如这次接入，就要求我们尽快把几处缺口补上。当然，也让我们验证了整条链路：

新增 os 条件：{ type: 'os', os: ['ios'|'android'|'windows'|'macos'|'linux'] }，从共享类型、网关与后台 resolver、套餐权限、规则编辑 UI 到 AI 助手 schema 全链路打通。UA 判定顺序有讲究——iOS 的 UA 里带着 like Mac OS X，必须先于 macOS；Android 的 UA 里带着 Linux，必须先于 Linux。
npx @dyqr/cli 装不上：发布到 npm 的 CLI 依赖被写成了未同步发布的 workspace 版本，真实用户的第一步 login 就会 404。
文档与 MCP 能力对不齐：Agent 技能文档写「只能去后台配分流」，实际 API 早已支持，但 MCP 没暴露参数。

三个问题都是在客户真实接入里暴露、修完后再在同一条链路上复验的。

适合谁

如果你也需要「扫码即分流」的二维码——App 下载引导、活动落地按渠道分流、按地区 / 设备给不同内容——不必在自己的后端重做一套 UA / GEO 判断。用 DYQR 短链 + Smart Routing 接管这一层：规则可随时在后台或 API / CLI / MCP 调整，二维码本身永远不用重新生成。