这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
技术挑战与决定
复杂得超出想象
老王继续介绍他们的业务场景，我意识到通知系统比想象中复杂多了。
通知类型：
- 评论通知：有人评论了你的动态
- 点赞通知：有人点赞了你的内容
- 关注通知：有人关注了你
- 系统通知：平台活动、促销信息
- 私信通知：收到私信
推送渠道：
- iOS：通过 APNs（Apple Push Notification service）
- 安卓：国内用不了 Google 的 FCM，需要接各家厂商推送（小米、华为、OPPO、vivo）
- 站内信：App 内部的消息中心
- 可选：短信、邮件
多端同步：用户可能同时登录手机、平板、电脑。怎么保证同步？已读状态怎么处理？
问题一个接一个。这不是一个简单的功能，而是一个完整的系统设计问题。
我的决定
面试结束后，我在楼下咖啡馆坐了很久。
- 大厂：系统架构都是现成的，成长空间有限。
- 创业公司：用户增长快，可以从零设计系统，虽然风险大但能学到很多。
我打开手机，给老张发了条微信：「我决定加入了，什么时候能入职？」
三分钟后，他回了一条：「太好了！下周一入职。我让 HR 准备 offer，对了，通知系统就交给你了，全权负责。」
看着那条消息，我既兴奋又紧张。这是我第一次独立负责一个系统的设计。
课程预告
接下来的章节，我将沿着时间线解决这些问题：
| 章节 | 要解决的问题 |
|---|---|
| 通知基础 | 认清通知的本质（三阶段、两种形式） |
| 推送渠道 | APNs 与安卓厂商推送、到达率 |
| 站内信 | 持久化消息中心、已读未读 |
| 多端同步 | 多设备状态一致 |
| 限流防骚扰 | 避免通知轰炸 |
| 偏好管理 | 让用户控制接收方式 |
| 系统架构 | 收束成完整设计 |
一句话
这一节是课程的问题定义：通知系统的复杂度来自「及时、可靠、不打扰」三者之间的平衡。带着这些挑战，我们开始第一章——重新认识通知。
发现内容有问题？
告诉我们哪里需要改进。