本篇是《独立开发者的平台寄生》系列的第 2 篇。第 1 篇讲「为什么渠道要先于产品」，本篇讲「多个渠道摆在面前时怎么选」。站内已有的 独立开发者生存指南 讨论的是方向与验证，独立开发者冷启动获客手册 讨论的是站外获客；本篇只处理平台渠道之间的取舍。
一、为什么需要一张矩阵
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
独立开发者选渠道，常见的两种极端：
一种是只选最熟悉的。因为自己用 Chrome，就做 Chrome 扩展；因为自己写代码，就做 VS Code 插件。熟悉度当然重要，但它只说明你能做出来，不说明用户在那里。
另一种是全部上架。同一个产品，同时提交 Chrome、Edge、Firefox、VS Code、Obsidian、Raycast，看起来覆盖面很广，实际上每个商店都要单独准备素材、单独过审、单独维护兼容性，最后每个渠道都只有几十个安装。
矩阵的作用不是替你做出决定，而是把「感觉这个渠道不错」拆成几个可以比较的维度，让你知道自己在为什么买单。
二、12 个渠道的全景
先把候选渠道摆出来。下面 12 个渠道覆盖了独立开发者最常见的软件产品形态：
| # | 渠道 | 典型形态 | 用户来这里做什么 |
|---|---|---|---|
| 1 | Chrome Web Store | 浏览器扩展 | 在网页里增强表单、列表、邮件、翻译、截图 |
| 2 | Edge Add-ons | 浏览器扩展 | 与 Chrome 类似，Windows / Edge 用户为主 |
| 3 | Firefox Add-ons | 浏览器扩展 | 注重隐私、开源、可定制的浏览器用户 |
| 4 | VS Code Marketplace | 编辑器扩展 | 写代码、查文档、生成片段、检查配置 |
| 5 | JetBrains Marketplace | IDE 插件 | 在 IntelliJ / PyCharm / GoLand 等工作流里增强 |
| 6 | Obsidian Community | 知识库插件 | 整理笔记、建立双向链接、可视化知识图谱 |
| 7 | Raycast Store | 启动器扩展 | 用键盘快速执行命令、查数据、控制应用 |
| 8 | Figma Community | 设计插件 / Widget | 在设计文件里批量处理图层、生成内容、检查规范 |
| 9 | Notion API 集成目录 | public connection | 授权访问所选内容、同步与自动化 |
| 10 | Slack Marketplace | 团队应用 | 在频道里接收通知、审批、查询、触发工作流 |
| 11 | Shopify App Store | 电商应用 | 在商家后台处理订单、库存、营销、财务 |
| 12 | WordPress.org | CMS 插件 | 在内容站点里做 SEO、缓存、表单、安全 |
这张表本身不回答「选哪个」，但它能帮你排除明显不匹配的渠道。比如你的产品是「帮设计师批量重命名图层」，那 Slack 和 Shopify 基本可以直接划掉；你的产品是「帮商家打印面单」，那 Chrome 和 Obsidian 也不该是主渠道。
Notion 付费模板市场应另行评估：它销售可复制的模板，已有平台支付，与 OAuth 集成不是同一种商品。本表保持 12 类候选，只把 Notion 行限定为 API 集成。
三、五个评分维度
下面五个维度，是我在比较渠道时最常用的。每个维度 1–5 分，5 分最好。
3.1 用户匹配度（权重 30%）
不是「平台有多少用户」，而是「平台里有多少用户正在做你的产品要增强的那个动作」。
- 5 分：用户每天在这个平台里重复做这个动作，你的产品能直接嵌进去。
- 3 分：用户会在这个平台里做相关动作，但需要改变一点习惯。
- 1 分：用户在这个平台里，但你的产品需要他换一个场景。
3.2 变现能力（权重 25%）
包括平台是否代收、是否支持订阅/买断/按量、抽成多少、退款谁处理、用户是否习惯为这类产品付费。
- 5 分：平台代收，支持订阅，用户有明确付费习惯。
- 3 分：平台不代收，但用户愿意为配套服务付费，或可以通过外部许可证变现。
- 1 分：平台用户强烈预期免费，且没有可行的付费路径。
3.3 审核确定性（权重 20%）
包括审核周期、拒绝率、拒绝理由是否可预期、权限变更是否触发重新审核、被封禁后能否申诉。
- 5 分：规则清晰、周期短、拒绝理由具体、可以快速修正重提。
- 3 分：规则基本清晰，但周期波动大，或某些权限容易卡住。
- 1 分：规则模糊、周期长、拒绝理由笼统，或封禁风险高。
3.4 技术复用（权重 15%）
同一个核心产品，迁移到该渠道需要重写多少。
- 5 分：同一套 Web 技术或同一套核心逻辑，加一层适配即可。
- 3 分：需要替换运行时或重写一部分 UI。
- 1 分：需要为平台从零实现一套架构。
3.5 维护成本（权重 10%）
包括账号费用、素材更新、兼容性测试、API 变更跟进、客服负担。
- 5 分：几乎没有持续成本，API 稳定，素材少。
- 3 分：每季度需要一次兼容性检查，素材需要定期更新。
- 1 分：API 频繁变更，多版本兼容，客服压力大。
权重不是固定的。如果你的现金流紧张，可以把变现能力提高到 35%；如果你只有两周时间，可以把技术复用提高到 25%。但用户匹配度不建议低于 25%，否则矩阵会把你引向「容易上架但没有用户」的渠道。
四、12 个渠道的示例打分
下面这张表以一个「网页效率工具」为假想产品：用户在浏览器里处理表单、列表和邮件，产品是轻量增强，订阅制，团队 1–2 人。
| 渠道 | 用户匹配 30% | 变现 25% | 审核 20% | 复用 15% | 维护 10% | 加权分 |
|---|---|---|---|---|---|---|
| Chrome Web Store | 5 | 3 | 3 | 5 | 4 | 4.00 |
| Edge Add-ons | 4 | 2 | 4 | 5 | 5 | 3.75 |
| VS Code Marketplace | 4 | 3 | 4 | 3 | 4 | 3.60 |
| WordPress.org | 3 | 3 | 4 | 4 | 4 | 3.45 |
| Obsidian Community | 3 | 2 | 4 | 4 | 5 | 3.30 |
| Firefox Add-ons | 3 | 2 | 3 | 5 | 4 | 3.15 |
| JetBrains Marketplace | 3 | 4 | 3 | 2 | 3 | 3.10 |
| Notion API 集成目录 | 3 | 3 | 3 | 3 | 4 | 3.10 |
| Slack Marketplace | 3 | 4 | 2 | 3 | 3 | 3.05 |
| Figma Community | 3 | 3 | 3 | 2 | 3 | 2.85 |
| Shopify App Store | 2 | 5 | 2 | 2 | 2 | 2.75 |
| Raycast Store | 2 | 1 | 4 | 3 | 4 | 2.50 |
计算方式：加权分 = 用户匹配 × 0.30 + 变现 × 0.25 + 审核 × 0.20 + 复用 × 0.15 + 维护 × 0.10。
这张表最重要的不是排名，而是它如何随产品变化。同一个渠道，换一个产品，分数会完全不同：
- 如果产品是「帮 Shopify 商家批量打印面单」，Shopify 的用户匹配和变现可重新给分，但其余三项也必须说明假设后重算，不能只改两项就宣称超过 4.3。
- 如果产品是「帮 JetBrains 用户检查代码规范」，JetBrains 的用户匹配、变现、复用都会上升，可能成为主渠道。
- 如果产品是「帮 Obsidian 用户做卡片盒笔记」，Obsidian 的用户匹配是 5，但变现可能只有 2，因为社区习惯免费插件；这时你要么接受「免费 + 赞助」，要么把付费点放到配套服务上。
所以正确的用法不是抄这张表，而是用同一套维度给你的产品重新打分。
五、怎么读这张表
5.1 先看用户匹配，不要先看总分
总分高但用户匹配低，通常意味着「这个渠道容易上，但用户不需要」。总分低但用户匹配高，可能意味着「这个渠道难，但值得投入」。
一个实用规则：用户匹配低于 3 的渠道，不作为主渠道。 它可以作为备选或实验，但不应该占用你最好的时间和素材。
5.2 变现能力要看「钱怎么到手」，不是「有没有付费用户」
有的渠道有大量愿意付费的用户，但平台不代收，你必须自己补账号、支付、许可证、退款、客服。这部分工作量要算进变现能力的评分里，而不是等上架后再补。
5.3 审核确定性是「时间成本」，不是「通过率」
一个渠道即使最终能过审，如果每次审核要等三周、每次权限变更都要重审，它对一个人的项目就是高成本。把它折算成「一年能发几个版本」，比看通过率更有意义。
5.4 技术复用决定你能不能「一鱼多吃」
如果你的核心逻辑是纯 TypeScript，那么 Chrome、Edge、Firefox、VS Code Webview、Raycast 之间的复用度可能很高；如果你的核心逻辑依赖某个平台的专有 API，复用度就低。复用度高的渠道，适合做「备渠道」；复用度低的渠道，只有在用户匹配极高时才值得单独投入。
六、渠道组合：1 主 + 1 备 + 1 自有
独立开发者最常见的资源误配，是把「多平台」当成「多收入」。更稳的组合是：
| 角色 | 数量 | 作用 | 选择标准 |
|---|---|---|---|
| 主渠道 | 1 | 承担大部分首批用户与收入 | 用户匹配最高、变现路径最清楚 |
| 备渠道 | 1 | 降低单平台风险，复用同一套核心 | 技术复用高、审核成本低、用户有重叠 |
| 自有渠道 | 1 | 沉淀可带走的资产 | 官网 + 邮件列表 + 文档，不依赖平台 |
主渠道怎么定
主渠道不是「总分最高」，而是「用户匹配 + 变现」两项都高的渠道。审核确定性可以靠经验补，技术复用可以靠工程补，但用户不在那里，补不了。
备渠道怎么定
备渠道的第一标准是技术复用。比如 Chrome 扩展做完，Edge 和 Firefox 往往只需要少量适配；VS Code 插件和 JetBrains 插件的复用度就低得多，不适合作为「顺手多上一个」的备渠道。
自有渠道为什么必须有
平台渠道给你的是「借来的分发」。一旦平台改规则、提高分成、封禁账号或算法变化，你需要一个不依赖平台的落点。官网不需要很复杂：一个产品页、一个定价页、一个邮件订阅、一个文档入口，就足够承接从平台导出的用户。
七、五种常见误判
误判一：把月活当匹配度
平台月活高，不代表你的功能有人用。要看「用户在这个平台里是否重复做你的目标动作」，而不是「这个平台有多少人」。
误判二：把「免费上架」当「成本为零」
免费上架不等于零成本。素材、截图、隐私政策、兼容性测试、审核沟通、客服，都是时间。一个渠道一年发四个版本，和一年发十二个版本，维护成本差三倍。
误判三：把「审核通过」当「有分发」
审核通过只是拿到入场券。平台内的搜索排序、榜单、推荐位、评分，才决定有没有人看见。第 9 篇会专门讲平台内增长。
误判四：把「多平台」当「多收入」
同一个产品在五个商店上架，如果每个商店都只有几十个安装，收入不会变成五倍，反而会把你的支持时间和更新节奏撕碎。
误判五：忽略支付能力
一个不代收的渠道，需要你自建支付与许可证；一个代收但抽成高的渠道，会改变你的单位经济。选渠道时就要算这笔账，而不是等收入进来才发现。
八、行动清单
- 写下你的产品要增强的那个「重复动作」，一句话，不超过 20 个字。
- 用第 2 节的 12 个渠道，划掉明显不匹配的，留下 3–5 个。
- 用第 3 节的五个维度，给留下的渠道逐项打分，算出加权分。
- 选出 1 个主渠道（用户匹配 ≥ 4、变现 ≥ 3）和 1 个备渠道（技术复用 ≥ 4）。
- 打开主渠道和备渠道的官方审核指南、支付文档，保存链接与快照日期。
- 写下自有渠道的最小构成：产品页、定价页、邮件订阅、文档入口。
- 给主渠道设一个 30 天里程碑：提交审核、拿到首批安装、拿到首批激活，三者至少完成一个。
矩阵不能替你冒险，但它能让你在冒险之前知道自己押的是什么。
使用边界与实操验收
12 行加权分只是一个假想网页工具的决策练习，已按明示权重复算；评分不是平台真实表现、用户量或审核通过率。法律与准入是先行否决项。
填写样例：Chrome 用户匹配 5、变现 3、审核 3、复用 5、维护 4，加权为 1.50+0.75+0.60+0.75+0.40=4.00。若 Notion 方案实际卖模板，重新开一行评价模板获客、支付地区与售后，不沿用 API 集成的 3.10。
关键参考与核验范围
以下链接支持对应的机制或规则；本文的案例、成本和经营评分是说明方法的假设，不能当作平台统计或收益承诺。核验日期：2026-10-22。
- Notion 付费模板销售 ：模板交易与 API public connection 的分发机制应分开。
- Notion 授权 ：public connection 使用 OAuth；内部连接和个人 token 各有范围。
- Shopify 应用分成 ：核对 App Store 注册费、累计收入资格、处理费与其他费用。
系列导航
- 上一篇：渠道优先：为什么独立开发者应该先选分发渠道，再定产品形态
- 下一篇：Chrome Web Store 上架：账号、Manifest V3、权限说明与审核拒绝复盘
- 回到目录：独立开发者的平台寄生
- 相关阅读：独立开发者生存指南（六）：变现与定价 、SaaS 早期定价：不要等产品完美后才收费
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。