17. 🔔 通知与推送 Notifications ★★★☆☆ App 专属
🌏 Web 网页规范
- 底层机制: Service Worker 配合 Push API 后台激活
- 呈现形式: 浏览器系统弹窗通知、站内小红点气泡
- 拦截状态: 必须显式征求网页通知授权
- 更新速度: 视网络请求挂载情况而定
📱 App 移动端规范
- 底层机制: 系统级 APNs / FCM 强常驻推送代理服务
- 呈现形式: 锁屏横幅、通知中心归档、App 图标角标
- 拦截状态: 深度植入系统权限配置列表，支持静默推送
- 更新速度: 秒级瞬间送达，支持后台静默唤醒 App 下载数据
应用内通知需要即时且克制。移动端特有 系统 Push 横幅通知，通过从顶部 Notch 刘海框向下滑入展示。支持右滑或上滑隐藏，配合导航栏上醒目的数字角标（Badge），引导用户及时查阅。
LIVE PLAYGROUND: 手机系统级 Push 推送通知下发交互模拟
点击触发按钮，观察 iOS 推送卡片从手机顶部 notch 滑下
弹出后，可以按住横幅向上滑动或是点击右侧进行清除关闭。
📋 大模型统一 Prompt (LLM Prompt)
邮件设计是 UI 的"考古现场"——由于 Gmail/Outlook/Apple Mail 的渲染引擎差异巨大，必须使用 Table-based 布局（非 Flexbox/Grid），内联 CSS（非外部样式表），并针对 Outlook 的 VML 渲染引擎做特殊回退。核心模式包括：事务邮件（订单确认、密码重置——信息密度高、CTA 单一）、营销邮件（hero 图 + 价值主张 + 单按钮 CTA）、摘要通知（多条消息聚合为 digest，减少邮件疲劳）。必须提供 纯文本回退（plain-text fallback），并遵循 单列 600px 最大宽度的行业惯例。
移动端通知设计不只是单条消息——需要 渠道编排策略（Channel Orchestration）：同一事件在不同紧急程度下走不同通道（即时 → Push 通知，非紧急 → 应用内通知中心，重要但非即时 → 邮件，关键 → SMS）。用户偏好管理界面应提供 粒度控制（按类型 × 渠道 × 频率 × 静默时段），避免"全开或全关"的二元选择。频率封顶（Frequency Cap，如每天最多 3 条 push）和 智能摘要（将多条合并为一条 digest）是减少通知疲劳的关键策略。