站内通知核心是用户与系统的轻量异步通信，需闭环实现生成、存储、读取、标记已读、分页展示，依赖notice_template和user_notice两张表，支持参数化模板、按用户隔离、状态管理及健壮渲染。
站内通知的核心设计思路
站内通知本质是“用户与系统之间的轻量异步通信”，不依赖邮件或短信通道，数据完全存在数据库中。关键在于：消息的生成、存储、读取、标记已读、分页展示这五个环节要闭环，且支持按用户隔离和状态管理。
数据库表结构设计（精简实用版）
至少需要两张表，避免过度设计：
- notice_template：存消息模板，如“您有 {count} 条新订单”——用占位符+参数化渲染，便于复用和国际化
- user_notice：每个用户每条通知独立记录，字段包括 user_id、template_id、params_json（如 {"count":"3"}）、is_read（tinyint）、created_at、expired_at（可选）
不建议用一张“notice”主表 + “notice_user_relation”关联表——小项目反而增加复杂度；大项目需推送到多端时再考虑解耦。
后端发送通知的常用方式
不是所有场景都实时发，要区分主动触发和批量补发：
- 业务操作中直接插入：比如订单创建成功后，调用
noticeService.sendToUser(userId, "ORDER_CREATED", Map.of("orderNo", "NO2025...")) - 异步解耦：用 Spring 的
@Async或发到 MQ（如 RabbitMQ），防止通知逻辑拖慢主流程 - 定时补发：例如每日早9点推送“昨日未读消息汇总”，用 ScheduledTask + 分页扫描未读记录
前端展示与交互要点
用户侧体验决定功能是否被感知：
- 顶部红点角标：查
SELECT COUNT(*) FROM user，缓存5秒内有效即可
_notice WHERE user_id = ? AND is_read = 0
- 消息列表页：按 created_at 倒序，分页查
user_notice，返回模板内容 + 渲染后文案（后端完成拼接，避免前端解析 JSON） - 一键已读：UPDATE 多条记录时用
IN (id1,id2,...)或WHERE is_read = 0批量更新，别单条循环 - 清空功能：软删（设 is_read=1 + expired_at=now）比物理删除更安全，留审计痕迹
