/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
一、应用分发是什么
应用分发，简单说就是把开发好的 App 安装包送到用户设备上并完成安装的过程。
从技术角度看，它包含几个环节：安装包的托管（APK / IPA）、下载入口的生成（链接、二维码、商店页面）、安装引导（Android 未知来源权限、iOS 证书信任），以及版本管理（谁该装哪个版本、旧版本如何下架）。
从渠道角度看，应用分发通常分为几类：
| 应用商店分发 | 某为、某米、OPPO、App Store、Google Play | 面向公开用户，需审核，适合正式发布 |
| 第三方分发平台 | 某公英、海哈游分发等 | 免审核或低门槛，适合内测、灰度、定向分发 |
| 企业内部分发 | 企业签名、MDM | 面向内部员工或特定组织，不走公开商店 |
| 内测分发 | TestFlight、第三方托管平台 | 面向测试人员，强调版本追溯和访问控制 |
| 网页 / 扫码分发 | 短链、二维码 | 常用于内测、活动推广、线下场景 |
所以“应用分发”是一个广义概念，既包括上架应用商店，也包括内测包托管、企业内部分发、扫码下载等场景。日常讨论里，很多人说的“分发”其实特指非商店渠道的分发，尤其是内测和第三方托管。
二、为什么需要 App 分发
1. 应用商店覆盖不了所有场景
应用商店适合正式版本，但有几个天然限制：审核周期长、版本更新要重新走流程、iOS 的 TestFlight 有 90 天窗口和人数限制、企业内部工具不适合公开上架。对于每天出包的敏捷迭代、客户演示、外包交付、灰度测试，商店渠道节奏跟不上。
2. 内测阶段需要可控的送达方式
内测包带着未公开的功能和代码逻辑，不能像公开版本一样随意传播。需要密码保护、下载次数限制、有效期控制，以及下载数据回传。微信和网盘只能解决“发出去”，解决不了“管得住”。
3. 版本事实需要一个可信来源
群文件命名靠人工约定，v2.3.1、v2.3.1-fix、v2.3.1-final 并存，测试反馈 Bug 时第一句话永远是“你装的哪个版本”。分发系统持有版本状态，下载页展示当前版本，历史版本可归档、可下架，版本事实从聊天记录转移到系统里。
4. 安装体验需要标准化
Android 的“未知来源应用”权限、iOS 的证书信任和描述文件，对非技术测试者来说都是障碍。分发平台把安装引导收敛到下载页上，减少在群里反复解释的成本。
5. 分发过程需要可观测
谁下载了、下载了几次、从哪个渠道来的，这些数据决定了分发是否可控。没有数据回传，分发就是一个黑盒，出了问题只能靠聊天记录回溯。
三、内测分发为什么需要专门的工具
如果按场景细分，内测分发是应用分发里对“控制”要求最高的一类：它不需要触达海量用户，但需要精确控制谁能装、能装几次、装的是哪个版本。
用微信或网盘做内测分发，本质上是把四层问题压缩成了一层：
| 传输层 | 包能否稳定到达，链接是否长期有效 | 部分覆盖，易过期 |
| 安装层 | 非技术测试者能否独立完成安装 | 基本空白 |
| 版本层 | 大家装的是否同一版本，旧版能否下架 | 依赖人工约定 |
| 控制层 | 能否限制转发、下载次数、数据回传 | 基本空白 |
这就是为什么内测分发通常会借助专门的托管平台。这类平台的能力差异，主要看三个维度：访问控制粒度、版本管理完整性、iOS 签名管理的收敛程度。
访问控制粒度决定你能不能按项目设置不同的密码和下载次数；版本管理完整性决定旧包能不能下架、历史版本能不能追溯；iOS 签名管理的收敛程度决定你是在一个后台统一管理企业签名、超级签名、TF 签名，还是在不同的证书和 plist 文件之间来回切换。
以海哈游分发为例，它在这三个维度上提供了对应的能力：按项目配置密码和下载次数、下载数据统计、iOS 多签名方式的统一管理入口。同类平台如蒲公英， 也覆盖了部分相同能力，差异主要体现在控制粒度和签名管理的整合方式上。选型时建议结合团队规模、迭代频率和签名管理需求做对比，而不是只看功能清单。
需要说明一个边界：分发平台解决的是“送达与控制”，不解决签名本身的有效性问题。 IPA 能否安装，首先取决于签名方式是否覆盖测试设备 UDID，或者证书是否被系统信任。平台只是把已经打好的包，用一条摩擦更低的路径送出去，并让发送方保留控制权。
四、自建还是用第三方：一个成本视角的取舍
有些团队会考虑自建分发系统。完全可控确实有吸引力，但实际成本主要不在开发，而在长期维护：
| 服务器与带宽 | 下载速度直接影响测试体验，带宽是持续支出 |
| HTTPS 证书 | 到期续期，遗漏即全员无法下载 |
| iOS 签名管理 | 证书、描述文件、UDID 维护，掉签需紧急处理 |
| 安装页兼容性 | 不同 iOS 版本、不同厂商浏览器的行为差异 |
| 统计与告警 | 下载量监控、异常告警需要额外开发 |
| 安全加固 | 访问日志、防刷、限流 |
对于没有专门运维支持的中小团队，这些维护工作会持续侵占研发时间。第三方平台的价值在于把这些模块产品化，团队只需要关注“上传—配置—分享”这条主链路。
反过来，如果团队已经有成熟的运维体系，或者对数据驻留有严格要求，自建仍然是合理选择。工具的价值取决于流程的复杂度，没有统一答案。
五、内测分发接入后的流程变化
无论用自建还是第三方，内测分发接入后，流程通常会收敛为四步：
上传：构建产物上传，平台解析应用名称、版本号、图标，生成下载页
配置：按项目设置密码、下载次数阈值、有效期
分发：二维码或短链发到对应测试群，密码单独告知
监控与下架：后台查看下载数据，测试结束后下架旧版本
变化的核心不在于“多了一个工具”，而在于版本事实的承载者发生了转移：从聊天记录转移到分发系统。测试人员打开下载页看到的就是当前版本，反馈 Bug 时有了客观的版本参照，不再依赖群文件命名和人工确认。
六、几个常见问题
iOS 包装不上怎么办？ 先确认签名方式。Ad Hoc 需要把测试设备 UDID 加入描述文件，企业签名需要信任证书，TestFlight 需要走苹果审核。分发平台不解决签名问题。
Android 安装提示“未知来源”？ 不同厂商手机设置路径不同，把引导说明放在下载页上，比在群里反复回答更省事。
密码设成多少合适？ 避免 123456 这类简单密码，建议“内测+日期”或随机字符串，并定期更换。密码和下载次数限制配合使用，控制效果更好。
测试结束后要做什么？ 及时下架旧版本，减少装错包和泄露风险。历史版本保留归档，便于问题回溯。
七、一句话总结
应用分发是 App 从构建产物到用户设备的“最后一公里”。商店分发解决的是“让所有人能装”，内测分发解决的是“让对的人装对的版本，并且管得住”。两者目标不同，工具和流程也不一样。
海哈游分发是内测分发方向上的一个可选项，可通过搜索“海哈游分发”了解其具体能力与限制。本文基于公开信息与流程实践整理，具体功能、限制及收费以官网说明为准。
