用户不会天天打开你的网站：vibe 项目通知系统实战指南

很多 vibe 项目死法都一样：上线那天 Product Hunt 冲了几百个注册，一周后日活掉到个位数。问题不在功能，在于用户走了之后，你没有任何办法把他喊回来。没有通知系统，你和用户之间就是单向的——他来你才知道，他走你只能干瞪眼。

所以我的立场很明确：项目上线第一天，就要具备通知能力。注意，不是第一天就把全套做完，而是从第一天起，代码里所有"需要告诉用户点什么"的需求，都走一个统一的通知入口。今天先接邮件，明天加推送、短信、企微机器人，都只是往这个入口后面挂新的渠道，而不是在十个业务文件里各写一遍发信逻辑。AI 写代码最爱干的事就是在每个调用处手写一遍 smtp.send()，三个月后你想改一句文案，得翻十个文件。

1. 先想清楚：通知解决的不是"发送"，是"召回"

通知系统的 KPI 不是"发出去多少封"，而是"把多少沉睡用户带回来"。想清楚这个，很多决策就顺了：

• 交易类通知（注册验证、订单、支付）：用户此刻非知道不可，实时性第一，允许打扰。
• 安全类通知（异地登录、密码修改）：同上，甚至值得用最贵的渠道。
• 召回类通知（你有 3 条新回复、降价提醒、周报）：这是通知系统真正的价值所在，但也是最容易被当成骚扰的一类，频率控制全部为它服务。
• 营销类通知（新功能、大促）：打开率最低、退订率最高，新手村建议直接不做。

判断：前两类默认开启、不可退订；后两类默认关闭或可一键退订。这个分级不是道德洁癖，是算过账的：被用户标记一次垃圾邮件，你的域名信誉掉的，比少发十封营销邮件的损失大得多。

2. 渠道选型：一张决策表，别凭感觉

常见渠道就五个：邮件、站内信、推送（App Push / Web Push）、短信、企业微信 / 飞书群机器人。按四个维度打分，选型就清楚了：

• 邮件：成本几乎为零，可带长内容、带链接；打开率 20%–40% 算健康。缺点是异步、进垃圾箱风险。适合：验证、订单、周报、召回。
• 站内信：零成本，打开率最高，但只触达"愿意回来的人"。适合：配合邮件做二次触达，App 内的铃铛小红点。
• 推送：触达率高、实时，但需要用户授权，且你得有个 App 或 PWA。Web Push 是小团队的平替方案。适合：即时互动提醒。
• 短信：到达率最高，成本最高，打扰性最强。适合：验证码、钱相关、安全风控。记住，短信是最后的手段，不是默认选项。
• 企业微信 / 飞书群机器人：B 端神器。往群里发一条 @所有人 的构建失败告警，比邮件管用十倍；C 端项目别碰，用户没有义务加你的群。

我的默认优先级：邮件 > 站内信 > 推送 > 企微 / 飞书机器人（B 端） > 短信。一个刚上线的 vibe 项目，先把邮件和站内信做好，能覆盖 90% 的通知场景。短信和 Push 等你真有 App、真有付费用户再谈。

3. 邮件实战：第一天就用 Resend，别自己搭 SMTP

这是全篇最坚定的一个判断：不要自己搭 Postfix / Sendmail 发信。IP 信誉、退信处理、FBL（反馈环）、黑名单申诉，每一个都能吃掉你一周时间，而你是个 vibe 开发者，时间应该花在产品上。Resend 免费额度每月 3000 封，5 分钟接好 API，域名验证按向导点几下就行。等你月发送量上 10 万封了，再迁到 AWS SES（约 $0.10 / 千封），那时候省下的钱才值得折腾。

发送代码长这样，全项目只允许这一个出口：

from resend import Resend
client = Resend(api_key=RESEND_API_KEY)
client.emails.send({
  "from": "VibeFix <notify@mg.yourdomain.com>",
  "to": user.email,
  "subject": render_subject("order_paid", {"order_no": order.no}),
  "html": render_template("order_paid", user.locale, {"order_no": order.no}),
  "headers": {"List-Unsubscribe": "<https://yourdomain.com/unsubscribe?token=...>"}
})

注意 from 用的是子域名 mg.yourdomain.com。判断：发信永远用专用子域名，别用主域名。万一发信域名信誉受损，主域名的正常邮件不受牵连，这是花 5 分钟配置能买到的最便宜的保险。

然后是域名三件套，一次配对，终身受益：

• SPF：一条 TXT 记录，声明"哪些服务器可以替我发信"。示例：v=spf1 include:amazonses.com ~all。新手用 ~all（软拒绝），确认无误再换 -all（硬拒绝）。Resend 后台会直接给你现成的记录，照抄就行。
• DKIM：用私钥给每封邮件签名，收件方用 DNS 上的公钥验签。记录形如 resend._domainkey 的 TXT。没有 DKIM，你的邮件在 Gmail 眼里就是"自称是你的陌生人"。
• DMARC：告诉收件方"验签失败时怎么处理"，并把报告发回给你。示例：v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com。关键节奏：p=none 先观察两周收报告，确认没有误杀再升到 quarantine，最后 reject。一上来就 reject，配错一个字符会把自己的合法邮件全杀掉。

邮件进了垃圾箱，按这个清单排查：去 Gmail Postmaster Tools 看域名信誉；新域名先预热，第一周每天从几百封起步慢慢加量；检查退订率，Gmail 对群发者的新规是垃圾邮件投诉率必须低于 0.1%，超过 0.3% 会被限流；正文别用短链接、别做成纯图片邮件；退订链接必须一键可用，别搞"登录后到设置页找开关"这种阴招。

4. 短信与推送：钱要花在刀刃上

短信只发三类：登录 / 注册验证码、钱相关（支付成功、提现到账）、安全风控（异地登录、密码被改）。营销短信一律不发——转化率低到不值得，还容易被用户投诉到运营商。算笔账：国内短信约 0.045–0.06 元 / 条，1 万用户每人每月收 1 条验证码，一个月 500 块左右，小项目扛得住；但国际短信贵一个数量级，用户一多就是无底洞。

再说个得罪人的判断：2026 年了，能用邮箱验证码 + TOTP 覆盖的场景，就别烧短信钱。邮箱验证码成本几乎为零，TOTP（Google Authenticator 那类）连成本都没有。短信只留给"收不到就完蛋"的关键路径，比如找回密码。很多 vibe 项目上线第一天就接短信验证码，一年烧掉几千块，其实 90% 的用户邮箱验证完全够用。

推送分两种情况：你有原生 App，就用 FCM / APNs，这是正道；你没有 App，别为了推送去套壳一个，Web Push 是小团队的平替，浏览器订阅、服务端用 Web Push 协议发，OneSignal 这类服务有免费额度，一套 API 同时管 Web 和 App。等 App 真做起来了再迁原生推送，迁移成本远低于你想象。

5. 模板与变量：别让 AI 在十个文件里各写一套文案

vibe coding 在这里有个经典坑：你让 AI"发一封订单确认邮件"，它就在 order.py 里手写一段 HTML；下次"发一封退款邮件"，它在 refund.py 里又手写一段。三个月后你要统一页脚加退订链接，得翻十个文件。正确做法：模板入库，发送只传模板编码 + 变量字典。

表结构最小可用版：notification_templates(code, locale, subject, body_html, version, updated_at)。发送时：notify(user, "order_paid", {"order_no": "20261008001", "amount": "¥99"})，由通知模块按用户语言取对应模板渲染。改文案只改数据库，不发布代码；要做 A/B 测试，加个 variant 字段就行。

两个硬规矩：第一，变量走白名单渲染，模板里不允许执行任意表达式，这是防 SSTI（服务端模板注入）的基本功，再小的项目也不能省；第二，模板里不写业务逻辑，"满 100 减 10 还是减 20"这种判断放在业务代码里算好再传进来，模板只负责排版。AI 特别爱在模板里写 {% if %} 套娃，review 时看到就拦下来。

6. 频率控制与退订：被当成垃圾邮件的代价，比少发一封大得多

召回类通知是最危险的：发少了用户回不来，发多了用户把你标记为垃圾邮件。Gmail 的 bulk sender 规则是硬红线，投诉率超 0.3% 直接限流，而且域名信誉掉下去要几个月才能养回来。所以频率控制不是"体验优化"，是"资产保护"。

• 合并（digest）：用户一晚上收到 3 条回复，发一封"你有 3 条新回复"而不是 3 封。实现很简单：召回类通知先进队列，每 30 分钟聚合一次再发。
• 按用户限流：营销 / 召回类，同一用户每天最多 1 封、每周最多 3 封。超了的直接丢弃并记日志，别排队等明天——过期的召回没有意义。
• 免打扰时段：22:00–08:00（按用户时区）非紧急通知不发短信和 Push，邮件可以发，反正它是异步的。
• 一键退订：营销类每封邮件带 List-Unsubscribe 头和正文退订链接，点一下即退订成功，不要登录、不要二次确认。你设置障碍，用户就直接点"这是垃圾邮件"，代价你付不起。

判断：退订是用户用脚投票的正常权利，把退订做顺滑的人，域名信誉反而更高。那些把退订藏起来的产品，最后都进了垃圾箱。

7. 失败重试与死信：发不出去的通知，要有下文

通知发送失败不能静默吞掉——"支付成功但用户没收到确认邮件"这种客诉，查起来全靠发送日志。所以通知模块要有三样东西：状态表、重试、死信。

状态表最小字段：notification_logs(id, user_id, channel, template_code, status, provider_message_id, retry_count, created_at)，status 就四种：pending / sent / failed / dead。每一封发出的通知都有迹可循，客诉来了 10 秒定位。

重试用指数退避：1 分钟 → 5 分钟 → 30 分钟 → 2 小时 → 12 小时，最多 5 次。注意两个细节：第一，幂等键，用 event_id + channel 做去重，重试时带上，防止网络超时导致用户收到两封"支付成功"；第二，主备 provider 自动切换，Resend 连续失败就切 SES 发，别在一棵树上吊死。5 次都失败的进死信（status=dead），然后告警到你自己的企微 / 飞书群——记住，通知系统自己的告警不能走通知系统，否则它挂了你最后一个知道。

8. 偏好设置页：把选择权还给用户，一页就够

一个合格的通知偏好页只需要三组开关，放在设置页最显眼的位置：

• 按类别：交易通知（默认开，不可关）、安全通知（默认开，不可关）、产品更新（默认开，可关）、营销推广（默认关，用户主动开）。
• 按渠道：邮件 / Push / 短信，允许用户关掉某个渠道（交易类短信关不掉，但可以降级为邮件）。
• 免打扰时段：让用户自己设，比如 23:00–07:00。

判断：营销类默认关闭。敢默认全开的，都是在透支域名信誉换短期打开率，账迟早要还。偏好页的每一项变更都要实时生效，并且写进日志——"用户明明退订了还收到邮件"是 GDPR / 《个人信息保护法》语境下最贵的客诉之一。

9. 上线验收清单：发出去之前，先过一遍

通知系统上线前，把下面这张表逐项打勾。别嫌烦，任何一项漏掉，线上都会以客诉的形式找回来：

• SPF / DKIM / DMARC 三条记录生效（用 dig TXT 或 mxtoolbox 验证），DMARC 处于 p=none 观察期。
• 发信域名是专用子域名（如 mg.yourdomain.com），不是主域名。
• mail-tester.com 自测 8 分以上；Gmail / Outlook / QQ / 163 四个种子邮箱实测进收件箱。
• 退订链接一键可用，退订后该类别不再发送。
• 频率限制生效：同一用户 1 分钟内触发 10 次召回，只收到聚合后的一封。
• 重试演练：mock provider 返回失败，确认 5 次退避重试 + 死信 + 告警链路全通。
• 幂等演练：同一 event_id 发送两次，用户只收到一封。
• 偏好页：每个开关实时生效，变更有日志。
• 监控告警：发送失败率 > 1% 告警、队列积压超过阈值告警、死信产生即告警。
• 模板检查：所有模板有中英双语版本，变量白名单外无多余占位符。

最后说句大实话：通知系统是 vibe 项目里投入产出比最高的基础设施之一。它不炫技，没有 AI 味，但它是你和用户之间唯一的桥。桥修好了，用户流失了你喊得回来，付费了他收得到确认，出事了你找得到人。花一个周末按这篇指南搭起来，值。