这是
content/posts/indie/indie-delivery-and-distribution的目录页，收录 10 篇文章。前面十三组分别讲「要不要做」「在哪上架」「丢了怎么找回」「怎么合法立住」「多条线怎么加减」「怎么用接单换现金」「前 100 天怎么走」「怎么让人知道你」「人来了怎么留住」「收多少钱」「用户不在你的语言里怎么办」「怎么判断做的东西是对的」「怎么让产品看起来像产品」。这一组补上最后一公里：代码写完之后，怎么让用户装得上、升得动、退得回、过得了审。
这个系列解决什么问题
一个人做产品，功能可以自己写，设计可以自己定，唯独「交付」最容易被当成打包那一下。而用户对产品的第一次判断，恰恰发生在安装与启动之间。
常见的四种情形：
- 自己机器上双击正常，用户下载后提示「无法验证开发者」。
- 更新器覆盖安装到一半失败，应用再也打不开。
- 新版本发出去，商店后台、更新清单与安装包写着三个版本号。
- 提交审核三次被拒，每次都因为材料不完整，发布计划只留了两天缓冲。
这一组不讨论框架选型与代码实现，只做一件事：把「送到用户手里」拆成一个人能执行、每步都有判据的动作。
核心主张：五条口径
第一，交付是产品的一部分。 装不上、升不动、被系统拦下，等于没做出来。
第二，签名不是可选项。 macOS 公证、Windows 信誉、商店沙箱各有硬门槛，成本要提前进计划。
第三，更新必须能撤回。 没有回滚通道的自动更新是单程票。
第四，审核要算进排期。 把等待天数与重提次数当成本，而不是意外。
第五，每条规则可验收。 一次通过率、发布前置时间、灰度阈值、回滚时间都能算，算不过就是没准备好。
10 篇速览
| 文章 | 核心内容 | 阶段 |
|---|---|---|
| 分发形态选择：直装、原生商店、包管理器与 Web 版的四条路 | 四种形态的四个责任人、每用户净收入、用户入口差异、一主一备加退出路径 | 选型 |
| macOS 签名与公证：Gatekeeper 拦截的六类原因与一次通过清单 | 签名与公证两道关卡、六类高频拦截、由内向外签名、三台干净机器验收 | 签名 |
| Windows 签名与 SmartScreen：OV、EV 与信誉积累怎么选 | 三种取得方式、签名链覆盖、警告期验收、证书生命周期与吊销应急 | 签名 |
| 安装包与更新器：dmg、MSIX、AppImage 与增量更新的验收 | 格式矩阵、安装卸载五面、架构与体积、更新器六项验收 | 打包 |
| 跨平台构建矩阵：三系统两架构的 CI 成本与发布前置时间 | 必需组合、CI 成本结构、密钥注入边界、产物保留与可复现 | 构建 |
| 崩溃上报与版本遥测：发布后 72 小时的止损阈值 | 四维字段、符号文件与去重、发布健康三指标、72 小时看板 | 观测 |
| 移动端内测与分阶段发布：TestFlight、封闭测试与 1% 灰度 | 内测轨道、设备矩阵、Apple 七天节奏与 Play 自定比例、四类暂停信号与全量判据 | 灰度 |
| 原生商店审核：Mac App Store、Microsoft Store 与 App Store 的拒绝点 | 四类商店差异、五类高频拒绝、提交材料清单、时间预算与申诉 | 审核 |
| 版本节奏与回滚：发布列车、兼容窗口与一次撤回 | 固定窗口与紧急通道、三处版本一致、N−2 兼容、回滚 runbook | 复盘 |
| 商店页素材：截图顺序、演示视频与版本同步验收 | 各商店素材清单、结果到流程的叙事、多语言套数、素材滞后验收 | 物料 |
三条阅读路径
路径 A：还没发布，正在准备第一个安装包
从 01 选定主形态与备形态，再按 02 或 03 完成对应平台的签名；然后用 04 定格式、跑一遍更新器验收。四篇做完，至少不会出现「自己机器能开、用户开不了」。
路径 B：产品已上线，更新总出问题
先读 06，把版本、渠道、架构、系统四个维度补上；再读 09，建立发布列车与回滚 runbook；最后用 05 检查构建矩阵，看哪一格在拖慢发布。
路径 C：准备上移动商店或原生商店
从 07 定内测轨道与灰度档位，用 08 逐项准备审核材料；上线后用 10 检查商店页与版本是否同步。若审核被拒，先按 08 的五类原因自查，再决定改产品还是换形态。
与其它专题的边界
| 专题 | 它讲什么 | 本组的边界 |
|---|---|---|
| 渠道优先：为什么独立开发者应该先选分发渠道，再定产品形态 | 渠道反向决定产品形态与技术栈 | 它讲「先选哪个渠道」；本组讲渠道已定之后，包怎么签、怎么装、怎么更新 |
| 渠道选型矩阵：12 个应用市场的用户、审核、分成、支付与维护成本 | 12 个应用市场的五维加权选型 | 平台间横向选型；本组是单条交付链路的纵向工程 |
| Chrome Web Store 上架：账号、Manifest V3、权限说明与审核拒绝复盘 | 浏览器扩展的审核、申诉与回滚 | 扩展归它；本组只处理原生应用，Chrome 仅作对照 |
| 平台合规：隐私政策、数据最小化、封禁申诉与开源许可 | 隐私政策、数据流图与合规义务 | 法律文本归它；本组只做遥测字段最小化与商店隐私申报的工程验收 |
| 代码与仓库：多远程、组织所有权、镜像与归档 | 发布产物「别丢、怎么找回」 | 本组讲产物「怎么签、怎么装、怎么升级」 |
| 商店开发者账号：Apple、Google、Microsoft 与 Chrome 的团队与找回 | 账号类型、费用、角色与找回 | 账号所有权归它；本组从「账号可用」之后开始 |
| 第 61–70 天：上线前的十五件事 | Web/SaaS 上线与支付冒烟 | 本组面向客户端交付物与商店审核 |
| 共享底座：账号、计费、邮件与部署的复用边界 | 多产品共享基础设施 | 本组是单产品从构建到更新的交付流水线 |
| 维护负债账本：依赖、证书与平台政策的季度巡检 | 证书与政策到期的巡检提醒 | 它负责「到期提醒」；本组负责签名、公证、审核的具体操作与通过判据 |
| 续费、年付与大版本升级 | 商业上的大版本再收费 | 本组是技术上的版本发布、兼容窗口与回滚 |
| 自有渠道：邮件列表、更新日志与推荐 | 更新日志作为获客内容 | 本组把更新日志当发布记录与回滚证据 |
| 视觉物料：图标、截图、演示图与素材清单 | 品牌物料的规格与生产 | 本组只做商店货架位的排序、各商店规格与随版本同步 |
| 商店页与搜索入口：翻译不是本地化 | 关键词与文案本地化策略 | 本组做视觉素材与版本同步，不重复 ASO |
| 本地化测试：漏译、回退与截图回归 | 多语言功能与界面测试 | 本组只做多语言商店素材的套数、替换与审核一致性 |
| electron介绍 | Electron 历史、特点与缺点 | 框架科普；不涉及签名、打包、分发与更新 |
| electron深入 | Electron 架构与主/渲染进程 | 架构原理；不涉及交付链路 |
| Vite 桌面应用实战：Electron 与 Tauri 的工程化落地 | 工程结构与构建，签名与更新仅概念级 | 本组给成本、通过判据、审核与回滚 runbook，不贴代码 |
| 一个人给产品加 AI：判据、成本、护栏与验收 | 四道判据与替代方案、推理账单与毛利下限、供应商打分、提示资产、50 条评测、事实边界、滥用防线、降级预案、额度与超额、四张验收表 | 本组：签名、公证、安装、更新与商店交付；该专题：AI 功能的成本、质量、权限边界与验收。 |
| 一个人的借力：外包、自动化与协作边界 | 借力顺序与回本、任务边界、试单与背调、brief、发包成本、设计内容与代码交接、自动化与客服、合作分成、四张验收表 | 本组：签名、公证、安装、更新与商店交付；该专题：发包、协作交接与净回收工时。 |
| 一个人的自助支持：帮助中心、排查树与工单减少 | 工单分类与可自助比例、任务型帮助中心、FAQ 与排查树、教程与截图、搜索空结果、更新日志、模板答复、三级升级、四张验收表 | 本组：签名、公证、安装、更新与商店交付；该专题：自助内容、排查树与人工升级。 |
| 一个人的消息系统：事务邮件、通知分层与送达率 | 消息清点、事务邮件基线、SPF/DKIM/DMARC、送达率账本、通知分层、偏好中心、渠道分工、生命周期序列、同意与退订、四张验收表 | 那组讲消息发出去能不能到；本组讲软件怎么签名、安装、更新与过审核 |
| 一个人的社区：冷启动、版规、版主与社群健康 | 社群该不该建、载体选型、前 100 人、版规与三档处置、版主与志愿者、内容节奏、答疑沉淀、活动与线下、商业化边界、四张验收表 | 那组讲用户社群的组织与治理；本组讲签名、公证、安装、更新与商店交付 |
| 一个人的财务：现金流、runway 与月度结账 | 四张表与四个收入、分账、收入确认、成本清点、13 周滚动、runway 与薪酬、15 分钟月结、税预提、现金预警与收缩、四维验收 | 那组讲钱的进出与结账；本组讲签名、公证、安装、更新与商店交付 |
| 一个人的运维：可用性、告警、事故与值班 | 可用性预算、五条探针、告警降噪、日志串联、状态页、容量水位、依赖降级、发布观察、事故复盘、四维验收 | 那组讲发布之后的观察与回滚；本组讲签名、公证、安装、更新与商店交付 |
| 一个人的多租户：组织、邀请、角色与数据隔离 | 组织引入判据、三层模型与迁移、邀请与成员生命周期、角色矩阵、三层校验、数据隔离、审计日志、席位一致、交接与四维验收 | 那组讲用户与数据边界；本组讲签名、公证、安装、更新与商店交付 |
| 一个人的产品度量：事件字典、指标口径与决策看板 | 六个决策与十二个指标、二十四事件字典、埋点三处校验、口径五要素、五步漏斗、一屏四区看板、四条校验与三方对账、采样与保留、样本量与灰度、九项验收 | 那组讲产品行为的度量口径；本组讲签名、公证、安装、更新与商店交付 |
| 一个人的架构：技术选型、模块边界与演进（10 篇） | 技术选型排除法、九个模块与依赖方向、数据迁移三步、四个升级窗口、技术债预算、三次规则、重构判据、可替换性、幂等与补偿、四维验收 | 那组讲代码结构与依赖；本组讲签名、公证、安装、更新与商店交付 |
| 一个人的计费系统：订阅状态机、按比例计费与失败重试（10 篇） | 订阅状态机、五个时点、按比例计费、按量计量、催收、退款拒付、发票税务、对账漏损、自建决策、十二项验收 | 那组讲订阅计费；本组讲签名、公证、安装、更新与商店交付 |
| 一个人的隐私工程：数据地图、最小化与删除权（10 篇） | 数据地图、最小化、合法性依据与同意、政策一致性、数据主体请求、删除、保留期、跨境与供应商、泄露响应、十二项验收 | 那组讲安装与崩溃遥测里的个人数据；本组讲签名、安装、更新与商店交付 |
| 一个人的数据搬家：导入、去重、迁移与退出（10 篇） | 迁移漏斗、导入契约、字段映射、去重合并、幂等重跑、人工代导入、窗口与回滚、附件限额、导出退出、十项验收 | 那组讲安装包与本地数据目录；本组讲签名、安装、更新与商店交付 |
| 一个人的质量守门：验证预算、回归清单与发布门禁（10 篇） | 47 缺陷与三条红线、12 条关键路径、三层配比、38→26 回归、六项门禁、四级缺陷、测试数据、不可逆保护、测试债、十项验收 | 那组讲发布前验证什么；本组讲签名、安装、更新与商店交付 |
| 一个人的安全基线：十四个入口、十七个密钥与一次 72 小时响应 | 14 个攻击面、认证与枚举、会话撤销、17 个密钥三档、四条边界、41 个依赖与 186 条告警、四类限流、9 类审计日志、72 小时三段响应、20 项验收 | 那组讲服务端与数据面；本组讲签名、安装、更新与商店交付 |
| 一个人的性能与账单：4.2 秒的首屏、一千二百次查询与每月 210 美元 | 4 项预算与 20 格、RUM 与慢查询、412→168 KB、1,200→3 次查询、0→86% 缓存、34 秒导出、7→4 个第三方、210→118 美元、3 次回归告警、10 项验收 | 那组讲传输体积与首屏加载；本组讲签名、安装、更新与商店交付 |
| 一个人的企业客户：九家询价、一百四十八道问卷与 134 天的第一单 | 9 家询价与 130 h、96 天采购、148 题问卷、7 个子处理者、SLA 43.2/216 分钟、26 h SSO、4 周试点、38 天到账、8 h 实施、10 项验收 | 那组讲企业客户的交付与支持；本组讲签名、安装、更新与商店交付 |
| 一个人的开源产品：4,200 个 star、一百八十个付费与一年 612 小时的维护 | 4,200 star 与 1,949 美元、612 h 维护、214 依赖、48,600 行 78/22、1,180 个 issue、214 条告警、23 个赞助者、9 家双许可、17 位贡献者、10 项验收 | 那组讲开源项目的发版与公告；本组讲签名、安装、更新与商店交付 |
本组统一口径
- 交付是产品的一部分：装不上、升不动、被系统拦下，等于没做出来。
- 签名不是可选项：三平台各有硬门槛，年费与等待都要进成本。
- 更新必须能撤回：原子替换、失败回退、旧包归档，三件缺一不可。
- 审核要算进排期：按最坏情况预留，而不是按最好情况许愿。
- 所有数字都是教学假设：每篇正文都标注了这一点，换成自己的产物重算才有意义。
使用说明
每篇都可以单独读，但建议按「先选形态、再签名、最后验收」的顺序。每篇末尾有行动清单与验收标准，验收标准写成了一句可判断真假的话——做不到就是没做完，不需要再解释。
文中出现的人物、产品与数字均为教学假设，用于演示算法，不代表经核实的真实案例。涉及证书、商店政策、隐私合规与审核规则的部分只说明取向，不构成法律意见，具体口径请以各平台当期文档与所在地法规为准。
本组的证据与使用方法
这十篇不引用任何平台的实时费率，也不承诺审核时效或转化提升。可复算的部分全部用四则运算给出算式（每用户净收入、签名成本、首次通过率、增量包占比、CI 成本、前置时间、止损阈值、灰度暴露人数、审核缓冲、回滚时间、素材滞后），读者可以替换成自己的数字重跑；不可复算的部分（例如证书取得周期、商店政策、信誉判定、审核结果）明确标注为需要自行核验，并给出核验方向。
建议的使用方式：先用 01 定形态，02–03 完成签名，04–05 把安装、更新与构建跑通；上线前用 06 埋好观测、07 设好灰度；08–09 处理审核与回滚，最后用 10 检查商店页与版本是否同步。交付不是一次性的打包动作，是一条每次发布都要重走一遍的链路。