分发形态选择：直装、原生商店、包管理器与 Web 版的四条路

选分发形态，本质上是在选「谁来替你签名、审核、更新和退款」。

一、上线三个月后才发现选错了路

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

程野做了一个批量重命名的桌面工具，定价 49 美元买断。第一个版本他直接上了 Mac App Store，理由很简单：有搜索入口，用户信任。

三个月后，账面上卖了一百二十份，实际到账比他预期的少了三成多。更麻烦的是三件他没想到的事：一次小修复因为审核卡了六天；一位用户要求退款，他只能让用户去找商店；还有用户问「Windows 版什么时候有」，而商店形态让他必须再走一遍另一套审核。

他后来加了官网直装，收入结构立刻变了，但新问题也来了：有用户下载后被系统拦下，写信问他是不是病毒。

这不是运气问题。四条分发路径的责任划分完全不同，选之前不把责任算清楚，后面每一步都会补一次课。

二、四种形态，四个责任人

把分发形态拆开看，每一种都在回答四个问题：谁签名、谁审核、谁负责更新、谁承担退款。

直装把控制权全给你，也把全部责任给你。 没有审核等待，但 Gatekeeper、SmartScreen 的警告要你自己消化；更新器要自己写；退款邮件的收件人是你。

原生商店把责任接过去一大半，代价是抽成与等待。 审核、支付、退款、更新分发都由平台承担，你换来的是「不用自己造这些」，也失去了「今天发现今天发」的自由。

包管理器适合开发者工具，但入口窄。 Homebrew、winget、Scoop 的用户群精准，安装体验干净，代价是你要维护一份清单、接受仓库审核，并且不能指望它带来新用户。

四条路的用户预期也不同。 商店用户默认「点一下就能装」，直装用户默认「要自己判断来源」，包管理器用户默认「升级由工具负责」。形态选错，用户会用错误的心智模型评价你的产品。

Web 版绕开了客户端交付，但不是免费。 没有签名与更新问题，换来的是服务器成本、浏览器兼容与「用户数据不在自己机器上」的信任门槛。

形态不是身份，可以叠加。 同一个产品完全可以商店 + 直装并行，但每加一条路，就多一份构建、签名与客服成本。加之前先问：这条路带来的是新用户，还是同一批用户的另一个入口。

叠加之前先算重叠。 商店与直装并行，通常有一部分用户会在两边都看到产品；如果两条路的定价、许可证与更新机制不互通，同一个用户会收到两套说法。

三、按净收入算，不按售价算

选型最容易犯的错，是拿售价比较。真正决定能不能养活自己的，是每用户净收入。

每用户净收入 = 售价 − 支付通道费 − 商店抽成 − 分发与签名成本

示例（售价 49 美元，均为教学假设）
直装：49 − 49×3% − 0 − 每用户约 0.6 = 约 46.9
商店：49 − 0 − 49×15% − 0 = 约 41.7
包管理器：49 − 49×3% − 0 − 每用户约 0.3 = 约 47.2
Web 版：49 − 49×3% − 0 − 服务器分摊 = 取决于用量

抽成比例要按实际档位算。 多数商店对小规模开发者有优惠档，但优惠有门槛与申请条件；用最高档估算会高估损失，用最低档估算会低估。

隐形成本要单列。 商店的素材规格、审核等待、隐私申报都是工时；直装的签名、公证、更新器与客服也是工时。把它们折算成小时，再和抽成放在同一张表上比较。

签名成本要摊到每用户。 苹果开发者年费、Windows 代码签名证书年费、公证等待的工时，除以年销量才是真实单位成本。年销一百份和年销一万份，同一个证书的摊薄差两个数量级。

分发成本不只是带宽。 安装包托管、更新清单、崩溃上报、商店素材制作与多语言，都属于「为了让用户装上」而付出的成本。

保本销量要用固定成本倒推。 把年费、证书、服务器与工具订阅加总，除以每用户净收入，得到「一年至少卖多少份才不亏」。这个数字比毛利率更能指导定价。

保本销量要按形态分别算。 同一款产品在商店与直装下的净收入不同，保本线也不同；用最低净收入的那条路做计划，才不会在切换形态时发现利润消失。

四、一主一备加一条退出路径

形态组合不需要复杂，三条规则够用。

第一条：选一条主形态，承担八成以上用户。 主形态要匹配用户在哪里找工具：面向普通用户选商店，面向开发者选直装或包管理器，面向团队选直装加集中部署。

第二条：留一条备形态，承担「主形态出问题时」。 商店审核被卡、账号被冻结、政策变化，都需要一个用户仍能拿到产品的地方。官网下载页是最低成本的备形态。

第三条：写下退出路径。 如果明天必须离开主形态，用户怎么迁移、许可证怎么继续有效、历史版本从哪里下载。写不出这条，说明主形态把你锁住了。

优先选「用户已经在的地方」，而不是「抽成最低的地方」。 一个没人搜索的商店，抽成为零也没有意义；一个用户每天都用的包管理器，哪怕要维护清单也值得。

入口的质量比数量重要。 一个能被目标用户搜到的商店入口，胜过三个没人浏览的目录站；选形态前先问「用户会用什么词找到这类工具」。

形态要跟着产品阶段变。 早期用商店换信任与支付，规模起来后用直装换利润与节奏，是常见路径。反过来做，往往在还没验证需求时先背上一套签名与更新工程。

切换形态要留迁移方案。 从商店转到直装，最怕的是老用户不知道该去哪更新；提前准备许可证迁移与旧版本下载页，比事后解释便宜。

五、行动清单与复算验收

• 列出候选形态，逐个写明谁签名、谁审核、谁更新、谁退款
• 用实际售价与抽成档位，算出每用户净收入
• 把年费、证书、托管、素材工时加总，倒推保本销量
• 选定一条主形态与一条备形态，写明各自承担的用户比例
• 写下退出路径：用户迁移、许可证延续、历史版本下载
• 估算每条形态的月维护工时，超过 8 小时的形态要削减
• 检查备形态是否能在主形态故障后 48 小时内启用
• 把选型结论写成一页，标注复查日期

验收标准：能说出主形态、备形态、退出路径，以及每用户净收入。 只回答「先上商店看看」的，说明还没算过账。

保本销量 = 年固定成本 ÷ 每用户净收入

示例：固定成本 2400 美元，净收入 46.9 美元
保本销量 ≈ 52 份/年

若主形态净收入 41.7 美元，同样成本需 58 份/年
两条路的差距，就是抽成与维护工时共同作用的结果

使用边界与实操验收

本文只做形态选型，不涉及具体渠道的评分与政策细节。平台之间的横向比较属于渠道选型矩阵：12 个应用市场的用户、审核、分成、支付与维护成本 ；「先选渠道再定产品形态」的判断属于渠道优先：为什么独立开发者应该先选分发渠道，再定产品形态 。

本文也不涉及签名、公证、安装包与更新器的具体操作，那些属于本组第 02 至 04 篇；商店账号的所有权与找回属于商店开发者账号：Apple、Google、Microsoft 与 Chrome 的团队与找回 。

验证以真实到账为准：连续三个月，把每条形态的到账金额、退款、支付费与维护工时记在同一张表上。三个月后如果某条形态的净收入低于维护成本，就该考虑关掉它，而不是继续「先留着」。

记录时把「到账金额」与「维护工时」放在同一行。只看收入，会忽略直装带来的客服与更新成本；只看工时，会低估商店带来的信任溢价。

另一个可复算的指标是形态重叠率：同时通过两条以上形态购买的用户比例。这个比例长期低于 2%，说明多形态只是增加了成本，没有带来增量用户。

第三个指标是形态切换成本：从一个形态迁移到另一个形态所需的用户沟通、许可证处理与素材重做工时。超过两周的切换成本，应当在选型时就写进风险清单。

关键参考与核验范围

本文的费率与示例均为教学演示，实际比例请以各平台当期政策为准。核验日期：2026-10-24。

• Apple Developer Program ：开发者年费、商店分发与审核政策的官方入口。
• Microsoft Store Policies ：微软商店的应用政策与分发要求，可用于对照直装与商店的差异。

上述两条只用于说明公开政策入口，不构成对任何平台条款的解释。抽成比例、退款规则与审核周期请以签约时的平台文档为准。

系列导航

• 下一篇：macOS 签名与公证：Gatekeeper 拦截的六类原因与一次通过清单
• 回到目录：一个人把软件交付到用户手里：签名、安装、更新与审核
• 相关阅读：渠道选型矩阵：12 个应用市场的用户、审核、分成、支付与维护成本 、商店开发者账号：Apple、Google、Microsoft 与 Chrome 的团队与找回