渠道不是越多越好，是每条消息只能有一个主渠道。
一、一条短信五美分，一夜之间发掉一百五十美元
孟舟的预约工具用短信发验证码，因为他觉得「短信最快」。单价五美分，每月八百条，四十美元，他觉得可以接受。
某个凌晨，一个脚本开始批量请求验证码，号码来自几十个不同号段。等他早上醒来，账号里已经发出去三千条，账单一百五十美元。更糟的是，真正的用户开始收不到验证码，因为当日额度被刷光了。
以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。
他补了四道闸：同号码每分钟一次、同 IP 每小时十次、请求前必须过人机校验、每日发送总额度设上限。同时把验证码主渠道改成邮件，短信只作为邮件失败后的备选。
渠道选择的第一个问题不是「哪个到达率高」，是「发错了要花多少钱」。 免费渠道发错只是打扰，短信发错是现金。
二、四个渠道：到达、成本、可撤回与打扰度
| 渠道 | 典型到达率 | 单条成本 | 可撤回 | 打扰度 | 适合的消息 |
|---|---|---|---|---|---|
| 站内信 | 登录时才看，打开约 35% | 0 | 可删除、可撤回 | 低 | 摘要、动态、产品更新 |
| 邮件 | 收件箱约 22% 打开 | 约 0.004 美元 | 不可撤回 | 中 | 事务、收据、周报 |
| 推送 | 授权用户约 8% 打开 | 0 | 不可撤回 | 高 | 即时、阻断 |
| 短信 | 接近 100% 送达 | 约 0.05 美元 | 不可撤回 | 最高 | 验证码备选、安全告警 |
到达率与打开率不是一回事。 短信几乎一定送达，但不一定被读；推送看起来即时，但授权率与打开率都很低。
可撤回是站内信独有的优势。 发错了一条站内信，可以删除并更正；发错的推送与邮件收不回来，只能再发一条道歉。
成本差两个数量级。 一条短信的钱可以发十二封邮件；把营销内容放进短信，是最昂贵的打扰方式。
主渠道只能有一个。 同一件事同时走四个渠道，用户会收到四遍；确定主渠道，其余只做失败回退。
渠道数量要跟用户的心智模型对齐。 用户心里通常只有两类：「应用里的消息」和「发给我的邮件/短信」。你内部有四条通路，对外的说法最好收敛成两类，否则每次解释都要花一段话。
成本不只是发送费。 每多接一个渠道，就多一套模板、一套失败处理、一套测试账号与一份对账；一人产品的真实成本在维护，不在单价。
渠道与合规规则是绑定的。 邮件要有一键退订，短信要有明确同意记录，推送受系统权限约束，站内信不需要退订但需要已读状态；选渠道时一起把规则定下来。
三、推送权限：什么时候要，失败了往哪退
推送的问题不在发送，在权限。
| 时机 | 索取权限的做法 | 结果 |
|---|---|---|
| 首次启动 | 一进来就弹系统授权框 | 拒绝率高，且难再要 |
| 完成首个价值动作后 | 先解释「开启后可及时收到 X」 | 授权率明显更高 |
| 用户主动打开通知设置 | 在设置页提供开启入口 | 精准但量小 |
| 已被拒绝 | 引导到系统设置，不重复弹窗 | 尊重用户选择 |
不要一启动就要权限。 用户还不知道你能给他什么，拒绝是理性选择；被拒绝后，系统通常不允许你再次弹出。
索取前先给理由。 用一句话说明「开启后，有人回复你时能立即收到」，比直接弹系统框有效。
推送失败要有回退链。 推送未授权或发送失败，降级到站内信；站内信 24 小时未读且属于即时级，再补一封邮件。
回退不能无限制。 一条消息最多走两个渠道；走三个渠道，用户会认为你在骚扰。
被拒绝不是终点，但要承认它是用户的选择。 可以在设置页留一个「重新开启提醒」的入口，但不要每隔一次启动就提醒他去开；反复劝说会把「不想被打扰」变成「不想用这个产品」。
Web 推送比原生推送更不可靠。 浏览器权限可以随时撤销，订阅会随清缓存失效；把它当主渠道的产品，必须有一份「订阅失效后转到邮件」的兜底逻辑。
四、短信：按条计费的四道闸
短信是唯一按条计费且可被恶意放大的渠道，必须假设会有人刷。
| 闸门 | 规则 | 防的是什么 |
|---|---|---|
| 单号码频率 | 每分钟 1 条，每小时 5 条 | 单个用户连点 |
| 单 IP 频率 | 每小时 10 次请求 | 单点脚本 |
| 人机校验 | 请求前完成一次轻量校验 | 批量脚本 |
| 每日总额度 | 超过阈值自动停发并告警 | 号段轮换刷量 |
四道闸要同时存在。 只限单号码，脚本换号即可；只限 IP，代理池可以绕；只有总额度，前三千条已经发出去了。
额度告警要发给自己。 到日额度的 50% 就提醒，不要等用完；一个人不可能盯着后台。
短信只留给验证码与安全告警。 营销、活动、召回都不该走短信，成本高且投诉率最高。
号码要校验格式与归属。 明显无效的号码在发送前就拦掉，能省下一批直接失败的短信费。
长短信按条计费。 一条短信超过编码上限会被拆成多条，账单上按条数算；验证码类模板控制在一百六十字符以内，别把整段说明塞进去。
按本例复算：
正常月份：验证码短信 800 条 × 0.05 = 40 美元
被刷当晚：3000 条 × 0.05 = 150 美元
多支出 = 150 − 40 = 110 美元（一晚）
若改成邮件主渠道：
800 封邮件 × 0.004 = 3.2 美元
短信只保留失败回退，按 3% 计 24 条 = 1.2 美元
合计 = 4.4 美元/月
渠道矩阵里的打开率
站内信 35% > 邮件 22% > 推送 8%
把验证码从短信换成邮件，一个月省三十五美元左右。 对一个独立产品，这不是大钱，但它把「被刷一晚一百五十美元」的风险一起拿掉了。
五、行动清单与复算验收
先定每条消息的主渠道，再谈回退。主渠道没定，回退链会变成多渠道群发。
- 为每条消息指定唯一主渠道，写进消息定义。
- 按到达、成本、可撤回与打扰度核对主渠道是否合理。
- 把推送权限索取改到用户完成首个价值动作之后。
- 为即时级消息配置「推送 → 站内信 → 邮件」的两级回退。
- 为短信配置单号码、单 IP、人机校验与日额度四道闸。
- 把营销类消息从短信与推送中移除，只保留站内与邮件。
- 设置日额度 50% 的告警，发到手机。
- 每月核对各渠道发送量、成本与打开率，找出性价比最低的一条。
验收标准：每条消息都能说出唯一主渠道与最多两级回退，短信只用于验证码与安全告警，且任何一次异常刷量都会在日额度 50% 时把你叫醒。
使用边界与实操验收
本文只处理一人产品的渠道选择与回退规则，不涉及推送平台的扇出架构、队列与回执，也不涉及客户端 SDK 接入。
多通道平台架构不归本文。 通道连接池、配额管理、到达回执与容量规划，属于系统设计；本文关心的是「这条消息该走哪条路」。
客户端推送实现不归本文。 APNs、FCM、Web Push 的令牌与订阅管理属于工程实现；渠道定完再选实现。
回退不是越多越好。 两级已经足够；三级回退会让同一条消息在三个地方出现，用户只会觉得你失控。
关键参考与核验范围
核验日期：2026-10-25。以下链接仅作为公开文档入口，用于核对 Web 推送的授权与订阅模型，本文未逐条引用其内容。
- W3C Push API ：用于核对推送订阅、权限状态与消息投递的标准模型。
- MDN：Push API ：用于核对浏览器端权限请求与订阅生命周期的一般说明。
引用口径。 本文只借用两份材料的标准模型：推送需要用户授权，订阅可能失效。文中的 800 条、3000 条、0.05 美元、35%、22% 与 8% 全部来自教学假设，与上述材料无关。
核验范围。 核验的是「四渠道矩阵 + 两级回退 + 短信四道闸」这套分工是否仍然可操作，不是比对某个推送或短信服务商的报价；具体价格以当期报价为准。
如何自行复核。 拉出最近一个月的渠道账单与发送量，算出每条消息的平均成本；任何一条营销消息走了短信，就先改它。
系列导航
继续阅读
探索更多技术文章
浏览归档，发现更多关于系统设计、工具链和工程实践的内容。