做过 APP 内测的团队几乎都遇到过一个场景：同一个版本需要同时分发给安卓和 iOS 测试用户，结果不得不维护两个下载链接、两张二维码，再在群里反复说明「安卓扫这个、苹果扫那个」。链接一多，下错包、装错版本的情况就很难避免。

本文从技术原理到实际操作，讲清楚「双端合并二维码」到底怎么实现，以及在内测分发中如何落地。

为什么需要双端合并二维码？

先回顾一下分开分发带来的实际问题：

• 沟通成本高：每次发版都要分别发送两条链接或两张二维码，测试用户容易混淆
• 下错包的概率大：特别是非技术背景的产品经理、运营同事，不确定自己该扫哪个码
• 管理维度翻倍：每个版本要维护两份分发记录，统计下载量时还得手动合并
• 对外展示不专业：如果是给客户或合作方演示，两个码并排贴显得粗糙

合并二维码的核心诉求很简单：一个入口，自动识别设备类型，下发对应安装包。

双端合并分发的技术原理

实现「一码双端」并不需要黑科技，核心逻辑分两步：

1. 服务端识别设备类型

当用户扫码打开分发页面时，服务端（或前端 JavaScript）通过 HTTP 请求中的 User-Agent 字段判断操作系统：

• 包含 iPhone 或 iPad → 识别为 iOS 设备
• 包含 Android → 识别为安卓设备
• 其他（如桌面浏览器）→ 展示通用提示页，引导用户在手机上扫码

这一步的准确率非常高，因为移动端浏览器的 User-Agent 格式是标准化的。

2. 按设备类型下发不同安装包

识别完成后，服务端返回对应平台的下载逻辑：

• 安卓：直接提供 app.apk 文件的下载链接，浏览器触发下载
• iOS：通过 itms-services 协议调起系统安装流程，背后需要一个部署在 HTTPS 服务器上的 .plist 文件，描述 IPA 的下载地址、Bundle ID、APP 名称等信息

两条路径在后端绑定同一个短链或二维码入口，用户侧感知到的就是「扫一个码，自动装对的包」。

关于 Plist 文件

如果你是自建分发服务，iOS 端的 Plist 文件需要手动编写并部署到 HTTPS 服务器。Plist 中至少包含以下字段：

• url：IPA 文件的 HTTPS 下载地址
• bundle-identifier：APP 的 Bundle ID，如 com.example.app
• title：APP 名称
• bundle-version：版本号，如 1.0.0

如果不想手动写 Plist，可以使用虾分发提供的 Plist 在线制作工具，填入对应字段即可自动生成。

在虾分发上如何操作合并分发

如果你不想自己搭服务、写 UA 判断逻辑，用内测分发平台可以在几分钟内完成。以虾分发为例，操作步骤如下：

1. 打开 虾分发官网，注册并登录账号，完成实名认证
2. 分别上传同一 APP 的 APK 文件和 IPA 文件，等待系统自动解析（解析完成后各自会生成独立的分发链接和二维码）
3. 进入【应用列表】，勾选需要合并的安卓应用和 iOS 应用，点击「合并应用」
4. 系统生成统一的二维码和短链接，测试用户扫码后自动匹配对应平台的安装包

合并后的二维码支持自定义 Logo 和样式，会员版二维码永久有效，不用担心链接过期。

建议：合并前确认两端的版本号和 APP 名称一致，避免测试用户混淆。如果某一端先发版，可以先上传单端包，后续再补传另一端并合并。

常见问题

自建 vs 平台方案的取舍

简单列一下两种路径的差异，方便团队决策：

• 自建分发服务：灵活度最高，适合有运维能力且对数据隔离有严格要求的团队；但需要自己解决 HTTPS 证书、CDN 节点、Plist 托管、UA 判断逻辑等问题
• 使用分发平台：开箱即用，上传 + 合并几分钟搞定；适合中小团队和快速迭代场景；数据统计、安全设置（下载密码、IP 白名单、次数限制）等能力现成可用

建议：如果团队内测频率高、版本迭代快，优先用平台方案降低运维负担；等规模大了、有定制化需求时，再考虑自建或混合方案。

总结

双端合并二维码的原理并不复杂——服务端识别设备类型，按平台下发对应安装包。难点在于工程侧的细节：HTTPS 部署、Plist 生成、CDN 加速、下载数据统计等。对于大多数内测场景，借助虾分发这类平台可以跳过这些基础设施工作，把精力留给产品本身。一个码解决双端分发，测试用户不用再问「我该扫哪个」。