这是
content/posts/indie/indie-messaging-and-notifications的目录页，收录 10 篇文章。前面十八组分别讲「要不要做」「在哪上架」「丢了怎么找回」「怎么合法立住」「多条线怎么加减」「怎么用接单换现金」「前 100 天怎么走」「怎么让人知道你」「人来了怎么留住」「收多少钱」「用户不在你的语言里怎么办」「怎么判断做的东西是对的」「怎么让产品看起来像样」「怎么把软件送到用户手里」「怎么把能力做成 API」「怎么给产品加 AI」「做不完时怎么借力」「同一个问题被问第一百遍怎么办」。这一组处理最后一件事：产品有用户之后，每一条自动发出的消息该不该发、走哪个渠道、能不能到、会不会打扰。
这个系列解决什么问题
消息是一个「加进去就没人拆」的功能。需求来时随手加一条：上线通知、试用到期提醒、有人评论、新功能公告。半年后产品里有三十八种消息，没有一份清单，没人说得清哪条还在发，也没人算过它们一共打扰了用户多少次。
常见的四种情形：
- 验证码进垃圾箱，用户说没收到，你查不出为什么。
- 每条通知都标「重要」，用户干脆全关，连扣款失败都错过。
- 邮件底部的退订点进去只能「全部退订」，想关周报的人连账单提醒一起丢了。
- 名单越导越大，投诉率悄悄逼近红线，而你连投诉是怎么来的都不知道。
这一组不讨论推送平台的架构，也不讲某个服务商怎么配，只做一件事：把「消息」拆成一个人能清点、能算账、能维护、能验收的一套系统。
核心主张：五条口径
第一，先清点再发送。 每条消息都要有触发点、收件人、渠道、紧急度、可否关闭、模板与负责人；缺一项就不该存在。
第二，事务与营销分开发。 子域名、发信身份、开关与退订规则全部分开；共享资源与声誉仍可能相互影响，分离便于控制，不代表完全隔离。
第三，通知要分层。 能等的不要打断，能合并的不要连发，能站内解决的不要发邮件。
第四，每条消息都要有出口。 退订、偏好、联系人与人工升级；必要通知按实际目的和适用要求处理，不用「事务」标签绕过偏好或抑制。
第五，所有数字都是教学假设。 换成自己的发送日志、退信表与真实时薪重算，才有意义。
10 篇速览
| 文章 | 核心内容 | 阶段 |
|---|---|---|
| 消息清点：一个产品到底需要发多少条消息 | 四类消息、七个字段、该砍的十二类、打扰预算 | 清点 |
| 事务邮件基线：验证码、重置与收据不能迟到 | 投递阶段、时效目标、持久去重、有效期重试、失败告警 | 基线 |
| 发信域名与认证：SPF、DKIM、DMARC 的最小配置 | 认证与对齐、现行标准、子域名边界、报告核对 | 身份 |
| 送达率账本：退信、投诉、垃圾箱与黑名单 | 最终状态、指标分母、投诉覆盖、抑制与恢复 | 送达 |
| 通知分层：什么该打断，什么该等 | 四级分层、四个动作、关闭率与到达率、打扰预算 | 分层 |
| 偏好中心：让用户自己决定收什么 | 三类开关、保存即生效、例外说明、回本周期 | 偏好 |
| 渠道分工：站内信、推送、邮件与短信怎么接 | 四渠道矩阵、权限时机、两级回退、短信四道闸 | 渠道 |
| 生命周期序列：欢迎、激活与召回各几步 | 三段序列、五个退出条件、全局频控、误发率 | 序列 |
| 同意与退订：订阅确认、退订时效与记录 | 四种来源、双重确认、一键退订、六项记录 | 合规 |
| 消息系统验收：送达、打扰、合规与成本四张表 | 十二项检查、比例评分、风险门禁、scale/fix/stop | 验收 |
三条阅读路径
路径 A：产品刚有用户，消息是随手加的
01 清点 → 02 事务基线 → 05 分层 → 06 偏好 → 10 验收。先清点并删减无用发送，再建立可观测时效与恢复路径，最后谈优化。
路径 B：邮件进垃圾箱、退信多、投诉高
03 认证 → 04 送达账本 → 02 重试与告警 → 09 同意与退订 → 10 验收。顺序反了，先改文案不会让邮件进收件箱。
路径 C：准备做召回或生命周期运营
08 序列 → 07 渠道 → 06 偏好 → 09 合规 → 10 复盘。先把退出条件写出来，再写第一封文案。
与其它专题的边界
| 既有内容 | 它讲什么 | 本组边界 |
|---|---|---|
| 自有渠道：邮件列表、更新日志与推荐 | 订阅入口、列表从哪来、更新日志 | 它讲名单怎么增长；本组假设名单已有，讲发出去能不能到、会不会被退订 |
| 召回：什么时候该叫醒沉默用户 | 召回时机、沉默分层与话术 | 它决定「该不该叫醒」；本组讲序列步数、间隔、退出条件与频控 |
| 流失分诊：先分清哪几种流失 | 流失原因分类与处置 | 它讲流失诊断；本组只处理召回消息的发送机制 |
| SaaS 激活邮件设计：让新用户在第一周完成关键动作 | 单篇激活邮件的内容与节奏 | 它是一篇激活邮件怎么写；本组覆盖欢迎、激活、召回三段序列与统一退出规则 |
| SaaS 流失挽回：从 0 开始把每一次取消都当成产品和销售诊断 | 取消流程、挽回动作与诊断 | 它管取消页与挽留；本组不碰取消流程，只在用户取消后停止序列 |
| 第 61–70 天：上线前的十五件事 | 上线清单，提过一次 SPF/DKIM/DMARC | 它只列一项；本组把认证做成可验收的步骤与检查表 |
| 第 81–90 天：反馈分诊与第一次收费 | 反馈分诊与首次收费 | 它讲怎么分诊；本组讲分诊结果里的通知怎么发 |
| 涨价：通知、老用户与过渡期 | 涨价通知的时机、措辞与过渡 | 它定内容与时机；本组定走哪个渠道、怎么分层、失败怎么兜底 |
| 定价复盘：价格、转化、留存与退款的一张表 | 退款率与定价复盘 | 它看退款率；本组看扣款失败与账单提醒的送达 |
| 更新日志与破坏性变更：让老用户知道发生了什么 | 四类变更、三档受众、告知覆盖 | 它讲告知内容；本组只讲这类通知的渠道选择与打扰控制 |
| 帮助中心的结构：按任务组织，不按功能组织 | 四层 IA 与五个入口（含邮件入口） | 它把邮件当入口之一；本组把入口侧的消息规则写全 |
| 模板答复与社区答案：把重复回复变成可复用资产 | 人工回复模板与变量 | 它管人写的回复；本组管系统自动发出的消息 |
| 共享底座：账号、计费、邮件与部署的复用边界 | 多产品复用同一套底座 | 它讲多产品怎么共用；本组讲单产品消息系统怎么做对 |
| 云账号与账单：扣款失败、额度与告警 | 云账号、扣款与额度告警 | 它讲账号安全与账单；本组讲发信额度、服务商切换与成本 |
| 事故响应：被盗、被封、被停机、域名劫持的 72 小时 | 账号、停机与域名事故的应急 | 它讲事故处置；本组讲事故通知该发给谁、走哪个渠道 |
| 开发者支持：工单分级、状态页与事故沟通 | API 开发者工单、状态页与事故公告 | 它面向开发者与事故；本组面向终端用户的事务与生命周期消息 |
| 对外 Webhook：签名、重试与幂等 | 机器事件的签名、重试与幂等 | 它是机器对机器；本组是人对人的消息，不重复事件投递 |
| 微文案：按钮、报错与空状态怎么说 | 应用内按钮、报错与空状态文案 | 它讲界面内一句话；本组讲邮件标题、正文与提醒文案的结构 |
| 合同与条款：服务条款、隐私政策、DPA、退款政策与试点协议 | 条款文本与政策 | 本组只给同意与退订的操作清单，不构成法律意见 |
| 年度合规日历与退出 | 年度合规动作与记录保存 | 它管公司合规日历；本组只讲营销消息的同意记录与保存期限 |
| 一个人把产品做出海：多语言、时区与本地化 | 文案外置、翻译、排版与时区 | 它讲产品文案；本组讲多语言消息模板、按收件人时区发送与本地退订入口 |
| 一个人把用户留住：激活、留存与复购 | 激活、留存、召回与续费指标 | 它看留存；本组看消息对激活与退订的影响，不重复留存口径 |
| 一个人的借力：外包、自动化与协作边界 | 一线客服外包与自动化边界 | 它讲人怎么接；本组讲不靠人值守的自动消息 |
| 消息推送平台设计 | 万人级推送平台的架构与扇出 | 它是系统设计；本组是一人产品的运营规则与发送账本 |
| 系统设计：通知系统 | 通知系统的队列、扇出与去重设计 | 它是面试式系统设计；本组不设计架构，只定发送规则 |
| 通知系统：通知类型、聚合去重、多端同步与推送架构 | 站内通知的类型、聚合与多端同步实现 | 它是完整产品级实现；本组只借用「聚合去重」的思路做打扰控制 |
| 推送通知：FCM、APNs 与本地通知调度 | 推送 SDK、令牌与本地调度 | 它讲怎么实现；本组讲什么时候该发、权限何时要、失败回退到哪 |
| 小程序订阅消息与消息触达体系 | 订阅授权、模板消息与到达限制 | 它讲平台独有的订阅模型；本组讲通用的同意与退订规则 |
| 游戏服务器玩家站内通知架构设计 | 站内信存储、已读与推送联动 | 它讲服务端架构；本组讲站内信的产品规则与清理 |
| 游戏通知优先级投递架构 | 红点、弹窗与系统消息的优先级与通道 | 它是多通道投递架构；本组只做四级业务分层与默认渠道 |
| Phaser 游戏内邮件与通知 | 游戏内收件箱的技术实现 | 它讲客户端实现；本组讲站内信的产品规则与清理 |
| 邮件安全与钓鱼防护实战 | 防钓鱼、伪造与邮件安全 | 它讲防御攻击；本组讲合法发信的身份与送达 |
| GitHub Actions 通知与 ChatOps | 构建通知、Webhook 与聊天集成 | 它把通知发给开发者；本组把通知发给终端用户 |
| 一个人的社区：冷启动、版规、版主与社群健康 | 社群规则、版主与公共沟通 | 那组讲多人场所里的公共沟通与成员治理；本组讲一对一的系统消息分层、渠道与送达 |
| 一个人的财务：现金流、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 项验收 | 那组讲开源项目的维护节奏；本组讲事务邮件、通知分层与送达率 |
另有一篇实现类的 Go 邮件模板入门：把验证码和通知邮件渲染清楚 ，讲的是模板怎么渲染与转义，本组不涉及；本组只定义消息的内容结构与验收口径。
本组统一口径
全组共用一组教学基线：可触达名单 1200 人（其中月活 800）、月发送 5000 封（事务 3000 / 生命周期 1500 / 公告 500，人均 4.17 封）、每封 0.004 美元、每月维护 6 小时、时薪 60 美元。事务算例以其中 3000 条为范围；其他指标分别固定投递单位、接收平台、时间窗与覆盖，不能只因同为「发送量」就共用分母。
月发送 5000 封
事务 3000（60%）
生命周期 1500（30%）
公告 500（10%）
人均 = 5000 ÷ 1200 = 4.17 封
发送费 = 5000 × 0.004 = 20 美元
维护 = 6 小时 × 60 = 360 美元
合计 380 美元/月
单位消息成本 = 380 ÷ 5000 = 0.076 美元
01 的对照口径：清点前 38 条消息、月发 7600 封、人均 6.33 封
清点后 26 条（事务 12 / 生命周期 9 / 公告 5）
事件口径：message_queued / message_sent / message_delivered
message_bounced / message_complained / message_opened
message_clicked / preference_changed / unsubscribed
投递口径：按逻辑消息与单收件地址记录最终服务器接受、最终退信与待定状态；尝试和原始回调另记。内部投诉占比采用本例指定分母，不能直接替代 Gmail 等平台自己的用户举报率；服务器接受不等于进收件箱。打扰口径：人均消息数按七日均值算，不按单日峰值。
使用说明
每篇都可以单独读，但建议按「先清点、再基线、最后验收」的顺序。每篇末尾有行动清单与验收标准，验收标准写成一句可判断真假的话——做不到就是没做完。
文中出现的人物、产品与数字均为教学假设，用于演示算法，不代表经核实的真实案例。涉及同意、退订、隐私与反垃圾邮件的部分只给操作清单与核验方向，不构成法律意见，具体口径请咨询所在地专业人士。
本组的证据与使用方法
这十篇不引用任何邮件服务商、推送服务或短信通道的实时价格与免费额度，也不承诺「分层一定提升留存」。可复算的部分全部用四则运算给出算式（打扰预算、退订率、投诉率、送达率、序列拦截量、误发成本、回本周期与综合分），读者可以替换成自己的发送日志与工时重跑；不可复算的部分（例如具体服务商报价、法规条文、平台审核规则）明确标注为需要自行核验。
建议的使用方式：先用 01 决定哪些消息该存在；02–04 建立身份、投递与恢复的观测基线；05–07 决定它们怎么打扰、能不能关、走哪条路；08–09 管住序列与同意；10 用四张表做季度验收。消息系统不是一次性项目，是一条随产品、名单与法规持续复核的线。