半泽和莉娜DormMate 新生宿舍管理系统赶在迎新季前上线的时候，最让我意外的是，首周被吐槽最多的不是床位分配，也不是入住流程，而是看起来最简单的通知公告模块。宿管老师的工作群一天能刷一两百条消息：今晚查寝提前到九点、3栋热水管爆了预计凌晨修好、消防演练集合位置变了、防诈骗讲座需要班级接龙……消息一旦淹没在聊天记录里，就总会有人没看到，学生没看到就不去，不去就反过来质问宿管“怎么没人通知我”。
新生宿舍管理系统里的通知公告，表面上只是“发一条消息出去”，但真要把这个模块做成能帮宿管减负、能逼着学生看到、还能让责任有据可查的功能，它牵扯到的问题一点不比工单系统少。这篇内容就围绕通知公告模块，复盘一下我在 DormMate 里做的需求拆解、数据模型、后端接口、前端交互，以及上线后排查过的几个典型问题。如果你也在写类似的宿舍管理、园区管理或校园服务系统，相信这些踩坑记录能帮你少走不少弯路。
1. 通知公告模块要解决什么问题
1.1 宿舍通知场景里被微信群放大的三个痛点
在做需求的时候，我没有急着画页面，而是先去宿舍楼里蹲了半天，看宿管到底怎么发通知。看完以后发现，宿舍通知的痛点不是“发不出去”，而是“发出去以后不可控”。
第一个痛点是消息会沉底。微信群里的通知发出去两小时，就被闲聊消息顶上去了，新生根本不会主动往上翻。尤其到了晚上，宿管要发第二天一早的停水通知，很多学生十点以后才看到，连蓄水的时间都没有。
第二个痛点是无法确认送达。宿管想知道到底有多少人看到了，只能靠“收到请回复”刷屏。但回复“收到”并不代表真的看懂了内容，反而把真正重要的信息全部淹没。
第三个痛点是缺少责任凭证。学生因为没看到活动通知而缺席，或者因为没看到安全检查通知而被记违规，最后扯皮的时候，宿管拿不出“对方确实看到了”的证据。人工截屏、口头确认，这些都不叫可追踪。
DormMate 接到的需求，其实就是要解决这三个问题。通知公告模块必须做到三件事：消息可以作为独立对象被推送到每个学生账号里，学生打开系统就能看到；系统能够记录“谁看过、几点看的”这样的已读回执；宿管可以针对不同楼栋、不同学院精准投放，而不是一个群聊全量轰炸。
1.2 角色权限与通知类型要怎么梳理
通知公告模块的角色很简单，但也不能只做成“管理员发、学生收”两级结构。在 DormMate 的实际场景里，角色一般分成四种。
系统管理员负责维护系统基础数据，也会代发一些平台级公告，比如宿舍管理规定变更；宿管员是日常通知的主力，维修停水、检查卫生、查寝安排都由他们发起；辅导员有时候需要定向通知某个学院或某几间宿舍；学生是最终接收方，只能查看发给自己范围内的通知并标记已读。
不同角色对应的是不同的数据范围。系统管理员发全局公告，范围是全体住宿生；宿管员默认只能管理自己负责的那几栋楼，不能越权把通知发给隔壁楼；辅导员能按学院、专业、班级选人。这里必须把“谁能发”和“能发给谁”两个维度都做干净，否则后面很容易出现通知误投、甚至隐私泄露的问题。
通知的类型我也拆了一下，大致分成了四类：维修通知（停水停电停梯、管道抢修）、安全提醒（消防演练、晚归管理、防诈骗宣传）、活动公告（宿舍文化节、卫生评比、社团纳新）、入住须知（新生入住流程、退宿办理提醒）。分类的目的不只是显示一个标签，它还会决定消息是否可以定时发送、是否需要置顶、已读回执是否需要加急催办。
1.3 功能清单怎么定才不会被宿管需求“反向抽打”
我第一版设计功能清单时，参考的是常见的新闻发布系统，写了标题、正文、发布时间、附件。需求评审的时候就被宿管老师当场问住了：那我想明天上午九点自动发一条通知，你们这个系统行不行？我想让通知在这几天之内一直显示在最上面，能不能设置？我能不能看到哪些学生到现在还没看？
所以通知公告模块最终的功能范围，是在这种真实反馈里慢慢被逼出来的。最终落地的核心功能包括：支持草稿和立即发布；支持定时发布；发布人可以撤回尚未过期的通知；支持指定楼栋、楼层、宿舍、学院等多种范围；紧急通知可以置顶；普通通知到了截止时间自动变为归档；学生端标记已读后，管理端能看到回执列表和未读名单。
也要做减法。有人说要有评论功能，有人要加点赞，我最后都没有做进去。宿舍通知不是社区论坛，不需要互动，加了评论反而会让学生讨论偏离正题、消息变得杂乱。做这种内部管理工具，每加一个功能都意味着后续的审核成本和舆论风险，边界感很重要。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 数据模型怎么拆：通知与已读回执必须分开
2.1 notice 主表：每条通知要存哪些字段
通知主表我命名为 notice，核心字段设计如下：
sql复制CREATE TABLE notice (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
title VARCHAR(128) NOT NULL,
content MEDIUMTEXT NOT NULL,
content_type TINYINT NOT NULL COMMENT '1-维修 2-安全 3-活动 4-入住须知',
notice_level TINYINT NOT NULL DEFAULT 2 COMMENT '1-紧急 2-普通',
status TINYINT NOT NULL DEFAULT 0 COMMENT '0-草稿 1-已发布 2-已撤回 3-已过期',
scope_type TINYINT NOT NULL COMMENT '1-全部 2-楼栋 3-楼层 4-宿舍 5-学院 6-自定义名单',
scope_ids VARCHAR(1024) NOT NULL COMMENT '范围ID列表，逗号分隔',
publisher_id BIGINT UNSIGNED NOT NULL,
publish_time DATETIME NULL,
scheduled_publish_time DATETIME NULL,
top_expire_time DATETIME NULL COMMENT '置顶截止时间',
revoke_time DATETIME NULL,
create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (id),
KEY idx_status_publish_time (status, publish_time),
KEY idx_publisher_id (publisher_id)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT = '通知公告表';
title 和 content 是基本字段，不需要多说。content 我用了 MEDIUMTEXT，也就是最大 16MB，正常宿舍通知很少会超过几万字，这个容量完全够用。scope_type 和 scope_ids 是通知的“发送范围”字段，我单独用一段来说明，因为这里特别容易设计失误。
2.2 接收范围：为什么坚持用“范围快照”而不是实时计算
很多人在做公告系统时，都会把范围字段存成一个 JSON，例如 {"buildings": [1, 2, 3]}，然后发布时根据这个 JSON 去员工表或学生表里实时查询有哪些人。这个做法在通知发布当时是准确的，但会带来很多隐性问题。
举个例子：9 月 10 日发布了一条针对 3 栋楼的通知，三天后，有位新生完成报到被分配到了 3 栋。这时候系统要判断“这位新生能不能看到 9 月 10 日那条历史通知”。实时计算范围的话，他会被算进去；但如果按业务理解，这位新生当时并不在 3 栋，他不应该收到那条已经发布过的消息。
DormMate 的做法是“发布时把接收人算好并落库”。我新增了一张 notice_target 表，字段是 notice_id 和 user_id 的组合，每发一条通知，就批量生成一批接收记录。
sql复制CREATE TABLE notice_target (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
notice_id BIGINT UNSIGNED NOT NULL,
user_id BIGINT UNSIGNED NOT NULL,
create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id),
UNIQUE KEY uk_notice_user (notice_id, user_id),
KEY idx_user_id (user_id)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT = '通知接收范围明细表';
这张表有两个作用。第一，学生端“我收到的通知”列表可以直接通过 user_id 查 notice_target 拿到，不需要再根据当时的楼栋分配关系二次计算；第二，撤回、已读统计、导出未读名单，都可以围绕这张表做，逻辑非常清晰。
代价是发布大范围通知时，可能需要生成几千甚至上万条目标记录。这个量级对 MySQL 来说其实很轻松，用批量 insert 一次性写入即可，根本不需要用消息队列异步慢慢塞。
2.3 已读记录表与状态机设计
已读记录是通知公告模块里最核心的状态数据，我单独建了一张 notice_read 表：
sql复制CREATE TABLE notice_read (
id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
notice_id BIGINT UNSIGNED NOT NULL,
user_id BIGINT UNSIGNED NOT NULL,
read_time DATETIME NOT NULL,
read_source TINYINT NOT NULL DEFAULT 1 COMMENT '1-详情页 2-列表页 3-推送触达',
PRIMARY KEY (id),
UNIQUE KEY uk_notice_user (notice_id, user_id),
KEY idx_user_id (user_id)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4 COMMENT = '通知已读回执表';
最关键的索引是 uk_notice_user，它保证了同一条通知同一个学生只能有一条已读记录。这样即使前端因为网络重发、学生反复点击，也不会产生脏数据。
从通知状态机来看，notice 表本身的 status 有草稿、已发布、已撤回、已过期四个状态。学生端针对每条通知还有一个“已读状态”，但这个状态不需要单独存字段，直接判断 notice_read 表里有没有记录就行。有人习惯在 notice_target 表上增加 read_time 字段，一步到位；我后来没有这样做，因为把发布范围和回执状态耦合在同一张表里，并发更新回执时可能产生行锁竞争。拆开以后，notice_target 只负责“你能看到什么”，notice_read 负责“你看了没看”，两个维度的增速不一样，拆开更方便独立扩展。
已读状态也不是永远不变的。如果通知被管理员撤回，那么用户视角这条通知会消失，但已读记录仍然保留在库里，以便后续责任追溯。我的处理是：撤回后前台默认不再展示，但如果后台需要导出“哪些人看过”，历史数据依然存在。
3. 后端接口与定时发布实战
3.1 发布接口的事务边界与前置校验
通知发布是最容易写“脏代码”的接口。很多人会先插入 notice，再插入 notice_target，然后把推送任务发到消息队列，三步写在一个 Service 方法里，最后发现数据库更新失败但推送已经出去了，学生都收到通知了，管理后台却查不到记录。
DormMate 的发布逻辑做了严格的事务拆分。核心事务只做两件事：写入 notice 主记录，写入 notice_target 明细。推送动作放在事务成功提交之后。代码结构大致如下：
java复制@Transactional
public Long createDraftOrPublish(NoticeSaveRequest request) {
Notice notice = new Notice();
notice.setTitle(request.getTitle());
notice.setContent(sanitizeHtml(request.getContent()));
notice.setContentType(request.getContentType());
notice.setNoticeLevel(request.getNoticeLevel());
notice.setScopeType(request.getScopeType());
notice.setScopeIds(String.join(",", request.getScopeIds()));
notice.setScheduledPublishTime(request.getScheduledPublishTime());
notice.setStatus(request.isToPublish() ? NoticeStatus.PUBLISHED : NoticeStatus.DRAFT);
noticeDao.insert(notice);
Set<Long> targetUserIds = targetResolver.resolve(notice.getScopeType(), request.getScopeIds());
List<NoticeTarget> targetList = targetUserIds.stream()
.map(userId -> new NoticeTarget(notice.getId(), userId))
.collect(Collectors.toList());
noticeTargetDao.batchInsert(targetList);
return notice.getId();
}
注意在 insert 之后，我调用了 targetResolver 去解析范围。这个解析过程涉及调用学生服务，会有网络开销，如果放在大事务里，会长时间占用数据库连接。所以我一般会把范围解析放在事务里但对其性能做出前置约束：单次解析不能超过几百毫秒，必要时提前把楼栋和学生的对应关系缓存到 Redis。
发布完成后推送动作怎么触发，我推荐两种方式：如果项目里已经引入了 RocketMQ 或 RabbitMQ，在事务提交后发送一条“通知发布事件”到队列；如果暂时没有 MQ，可以在事务方法里使用事务同步器，注册 afterCommit 回调来触发推送。绝不能直接在事务内部调用推送服务，否则一旦推送接口超时，整个发布请求会被拖死。
3.2 定时发布怎么实现，为什么不能裸用 @Scheduled
宿管的需求里，经常会有“请今天晚上十点自动发送明天停水通知”这类的定时任务。定时发布听起来简单，真做起来有个坑：宿管在管理端设置好定时发布后，学生立刻收到了通知。这种情况往往不是定时任务逻辑写错了，而是没有区分“数据库里的发布时间”和“任务扫描时间”。
DormMate 的做法是一张定时扫描任务。我启动了一个每分钟跑一次的定时任务，扫描 notice 表里 status 为草稿或已发布状态、scheduled_publish_time 小于等于当前时间、且实际 publish_time 为空的记录，把它们批量置为已发布状态，并补上 publish_time。
java复制@Component
public class NoticePublishScheduler {
@Scheduled(fixedDelay = 10000)
public void scanDueNotices() {
if (!distributedLock.tryLock("notice:publish:scan", Duration.ofSeconds(30))) {
return;
}
try {
List<Notice> dueList = noticeDao.selectDuePublishList(new Date());
for (Notice notice : dueList) {
publishNoticeInternal(notice.getId());
}
} finally {
distributedLock.unlock("notice:publish:scan");
}
}
}
这里有几个关键点。
第一是分布式锁。如果 DormMate 部署了多个实例，每个实例都会跑一遍这个定时任务，没有锁就会造成同一条通知被发布两次。加锁有两种思路，一种是抢一个全局锁，只有抢到的实例执行任务；另一种是在数据库层面更新 notice 时加上条件 WHERE id = ? AND status = 0，更新行数为 0 说明别人已经发布过了。两个手段我建议都用，前者减少无意义扫描，后者兜底保证幂等。
第二是时间的统一。scheduled_publish_time 我规定必须使用服务器本地时间，前端提交时也要先转成时间戳再传，避免不同时区带来的误差。宿舍管理系统的用户基本都在国内，这块简单处理就行，但千万别用 new Date().toString() 这种格式在前后端之间传输。
第三是扫描频率。我用的是 10 秒一次，对宿舍通知来说完全够用。如果追求秒级发布，可以把频率改到 1 秒，但要注意对数据库的压力，尤其当 notice 表没有加索引时，每秒一次全表扫描会很难看。我在 notice 表上建了 idx_status_publish_time (status, publish_time)，扫描时直接利用索引。
3.3 已读回执接口要怎么保证幂等和计数准确
学生端点击“标记已读”是一个高频率动作，而且前端一般会异步多传几次。如果没有做幂等，很容易出现重复已读记录，或者已读数量越加越多。
我在 notice_read 表的唯一索引已经能挡住重复插入，但“已读数量”这个汇总值不能简单地在每次插入后加一。更安全的做法是插入成功后再去更新统计。代码大致如下：
java复制public void markRead(Long noticeId, Long userId) {
int inserted = noticeReadDao.insertIgnoreConflict(noticeId, userId, new Date());
if (inserted == 1) {
noticeStatCache.incrementReadCount(noticeId);
}
}
insertIgnoreConflict 要用数据库的 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE，这样即使重复请求也只是影响行数为 0，不会再走一次统计更新。
已读数量的展示我其实并没有实时去 count 明细表。原因很简单：一条面向全校 8000 人的通知，每次打开列表都要 SELECT COUNT(*) FROM notice_read WHERE notice_id = ?，几万人同时使用时会变成数据库的噩梦。我在 Redis 里为每条通知维护了一个已读计数字段，发布时初始化为 0，学生点已读时递增。列表页直接读缓存即可。
这里要特别提醒一个坑：Redis 计数可能会因为重启、过期等原因丢失，所以缓存只能用来做展示，不能用来做最终统计。后台导出的“未读名单”必须走明细表实时查询。我在每天凌晨会跑一个对账任务，把 notice_read 表的真实计数拉出来和 Redis 缓存里的值做比对，发现不一致就修正，避免管理端看到“已读 1999 人”，导出明细只有 1980 条这种情况。
3.4 消息推送与离线兜底的设计取舍
通知发布后，不能只躺在系统里等学生自己点开。学生端如果没打开 App 或小程序，通知很难被注意到。DormMate 的通知公告模块接入了两条推送链路。
第一条是站内推送。前端通过 WebSocket 和服务器保持长连接，通知发布后服务端通过这个通道向目标用户实时推送一条“你有新通知”的消息，前端收到后把红点点亮。WebSocket 的优势是实时性好，缺点是连接并不一定稳定，尤其学生在宿舍里网络切换频繁时，连接容易断开，所以它只能作为提醒手段。
第二条是短信/微信模板消息兜底。我最初不想加这条，因为每条都有成本。后来看后台数据才发现，所有学生里大概有 15% 的人在通知发布后的 4 小时内根本没有打开过系统。对于紧急维修通知来说，这批人没看到就会在停水时不知所措。所以最终我设计了一个策略：普通通知不触发短信，紧急级别通知在发布后 30 分钟仍未读时会触发一次短信提醒。
推送通道在设计时要遵循一个原则，就是“不阻塞主流程”。推送失败不能影响通知状态和已读功能。我在发送推送事件时用了异步线程池，并配置了熔断，短信通道挂掉也只是少发一批提醒，系统核心的发布和回执能力不能跟着一起挂。
4. 管理端与学生端的交互细节
4.1 管理端发布台：真正难的不是富文本，而是“范围选择”
管理端页面主要由三部分组成：通知列表、富文本编辑框、接收范围选择器。列表页面负责展示草稿、已发布、已撤回记录，提供编辑、撤回、置顶操作。
富文本编辑我用的是常见的 wangEditor，功能上足够的。接入的时候遇到两个问题：一是剪贴板粘贴过来带了一堆 Word 样式，提交的 HTML 非常脏；二是学生端详情页直接用 v-html 渲染时，存在 XSS 注入风险。这两个问题我放在后面的排查部分细讲，但方案在管理端就要想好：提交时必须做 HTML 清洗，只保留 p、strong、span、img 等少量标签。
真正难的是接收范围选择器。宿管最常见的操作是“给一栋楼里 220 室到 260 室的同学发通知”，而不是简单的全选。范围选择器需要同时支持按楼栋、按楼层、按宿舍区间、按学院，并且在选择后要能够预览人数。我做了一个递进式选择面板：先选组织维度，再选具体节点，确定后展示选中范围和命中人数。
范围选择器的数据源和 notice 主表的数据源是一致的。所以这个页面每次查询时都比较重，必须加 Redis 缓存，比如把“3栋的当前住宿学生 ID 集合”缓存起来。发布时如果命中缓存，就直接从缓存批量读取，避免每次都去数据库里扫描住宿关系表。
4.2 学生端消息中心：红点逻辑要干净、可清零
学生端我做的不是一个简单的“公告列表”，而是一个消息中心。登录后首页右上角有一个通知图标，上面挂红点。红点的逻辑看起来简单，实际上很容易做乱。
我的方案是：红点显示的条件是“存在当前用户可见、且未读、且状态为已发布的通知”。这三个条件缺一不可。如果通知已撤回，即使没读也不能让红点一直亮着；如果通知已标记过期，同样不能再骚扰用户。
列表页分三个 Tab：全部通知、未读通知、维修通知。为什么单独做了维修通知 Tab？因为我观察宿舍场景里，维修和停水停电位居学生搜索第一位，把这类通知单独拎出来，学生能更快判断今天是不是要受影响。
学生端列表接口返回的数据结构大概是这样：
json复制{
"cursor": "20240901120000123",
"hasMore": true,
"items": [
{
"noticeId": 10001,
"title": "3栋热水管抢修通知",
"contentType": 1,
"noticeLevel": 1,
"status": "published",
"readStatus": 0,
"topExpireTime": "2024-09-02 18:00:00",
"publishTime": "2024-09-01 09:00:00"
}
]
}
readStatus 字段是我在后端通过当前用户 ID 和 notice_read 表关联查出来的，不在接口层做二次判断。前端拿到后如果 readStatus 为 0，且当前页面在列表首屏，就调一次批量已读接口。批量已读可以减少请求次数，否则学生一打开列表，N 条未读就会并发发出 N 个接口请求，直接把自己的服务端打哑。
4.3 服务端时间与分页“游标”那些容易翻车的小细节
学生端接口我强制要求前端不能使用本机时间。很常见的 bug 是：通知发布时间是北京时间，但学生手机系统设置成了其他时区，或者手机时间不准，显示出来就是“刚刚发布”或者“未来时间”。所以在接口层，所有时间字段我都返回毫秒时间戳，前端统一用一个全局函数格式化。
分页方面我最初用的是传统 pageNum/pageSize，后来发现在消息中心这种高频滚动列表里，用户很容易一直下滑翻到几百条以后，MySQL 这种深分页场景下 pageNum 越大查询越慢。我把分页方式改成了游标分页，以 publish_time 和 notice_id 组成复合游标。
查询条件大致是：如果传入的 cursor 非空，就加上 WHERE (publish_time < ?) OR (publish_time = ? AND id < ?)，然后 order by publish_time desc, id desc limit 20。这个方案在数据量超过十万以后依然能够稳定使用，排序也不会出现重复项。
5. 上线后的问题复盘与排查技巧
5.1 已读人数和明细对不上：问题出在“先查后插”
上线后第一周，宿管老师反馈：3栋有一条停水通知，管理后台显示已读 182 人，但导出的已读名单只有 178 条。我排查后发现，不是统计功能 bug，而是我在早期写的标记已读方法是“先查询有没有记录，没有就插入”，这种 check-then-act 模式天然存在并发安全问题。
学生点已读时，前端可能会并发触发两个请求。两个请求同时执行查询，都查到不存在，然后都执行插入，数据库层面的唯一索引挡住了第二条，代码却以为插入成功了，Redis 计数就被多加了。第一版代码里没有在插入后根据影响行数判断是否真的成功，所以导致计数虚高。
解决方式就是前面写的，用 INSERT IGNORE 加唯一索引，以数据库返回的影响行数作为唯一可信依据。修复后我还跑了一次全量对账脚本，把 24 小时内不一致的计数全部重新从明细表统计修正。
这里也提醒大家一个经验：任何涉及“检查后再写入”的接口，都一定要把数据库的唯一约束当作最后一道防线。不要相信代码里的 if 判断在多线程环境下的安全性。
5.2 定时任务偶尔失效或重复发布
定时发布出过一个线上事故。凌晨 0 点有一条水压测试通知应该发布，宿管第二天看到后台发现这条通知还在草稿箱里，但同一天的另外两条通知发送正常。
排查日志后发现，原因是定时任务线程池中某一次请求积压，导致扫描任务执行时间超过了调度间隔，后面的任务被阻塞；再加上当时那个实例出现了短暂的 GC 停顿，任务执行被延后了不少。虽然理论上任务最终会执行，但宿管看到的结果是“没发”。
我调整了三个地方。第一，扫描任务改为每 10 秒一次，但执行逻辑里把整个列表的发布时间遍历改成分批处理，每次只处理当前一分钟内到期的记录，避免积压。第二，给分布式锁增加了等待时间。第三，加了告警：扫描任务如果发现一批本该在 5 分钟前发布、却仍然滞留的记录，立刻通知开发人员，防止静默失败。
另外还有一个容易犯的错误：为了追求“整点发布”，任务代码里写 if (now.getSecond() == 0)，结果因为线程调度延迟，跳过了恰好是整秒的窗口，任务就没执行。正确写法是判断 scheduled_publish_time <= now，而不是判断 now == scheduled_publish_time。
5.3 撤回通知后的数据一致性
有次宿管误发了一条写错楼栋的通知，紧急撤回后，学生还是陆续来找宿管问“那个通知怎么打不开”。我一开始以为前端没有把撤回状态同步过来，后来发现是撤回接口只改了 notice 表的 status，没有同步清理 WebSocket 已经推送出去的内容和客户端本地缓存。
由于 WebSocket 是实时推送的，消息一旦到客户端，就算服务端把通知删了，很多学生端本地已经缓存的列表里依然保留着这条记录。光靠前端启动时拉取接口不够，必须做两件事：撤回动作通过推送通道给在线用户发送一个 recall 事件；学生端收到 recall 后，主动从本地缓存和当前页面中移除或标记该条通知。
我补充的撤回事件消息结构很简单：
json复制{
"event": "notice_recall",
"noticeId": 10001
}
学生端收到后，如果当前列表里有这条记录，就将它从列表中移除；如果学生已经点开详情页，则显示“该通知已撤回”。
撤回后的历史数据在管理后台依然可见，只是状态标签改成“已撤回”。宿管也需要这个功能来追溯自己误发的事故，不能把数据物理删除。
5.4 置顶排序出现跳变，问题出在排序字段
置顶功能是我提测前认为最简单、上线后却被反复吐槽的一个点。现象是：宿管把一条通知置顶后，列表头部确实变了；但当第二条通知被置顶时，原来的置顶通知会突然沉到下面去，而不是停在第二的位置。
代码里原来的排序是 ORDER BY is_top DESC, create_time DESC。看起来没问题，但置顶操作时我没有更新 create_time，而是只把 is_top 置为 1。当出现两条置顶通知时，它们的排序还是要根据创建时间，新置顶那条如果创建时间更早，反而排在旧置顶的下面，体验特别奇怪。
我的修正方案是给 notice 表增加一个 top_time 字段，置顶时更新为当前时间。排序改为 ORDER BY top_time DESC, publish_time DESC。普通通知的 top_time 为 NULL，置顶的排在前面，置顶通知之间按照最新置顶时间排序，这样管理者每次操作都符合直觉。
这类排序 bug 其实在评论、公告、工单系统里经常出现，本质原因是把“操作时间”和“创建时间”混用。不要嫌多一个字段麻烦，操作行为就需要对应的时间字段。
5.5 通知列表越翻越慢，分页和缓存要一起改
上线一个月后，通知表积累到几万条，学生的未读数也越来越多。有段时间学生反馈消息列表要等两秒才能打开，我查了一下慢查询日志，定位到两个瓶颈。
第一个瓶颈是列表页的 count 查询。每次查询未读 Tab 都要做一次 COUNT(*)，几万条未读数据时 count 本身就慢。前端实际上只需要知道“有没有未读”来决定红点显示，不需要知道精确的未读总数。我改成了用一个 Redis key 存储“当前用户未读数”，读接口只返回一个布尔值，彻底砍掉了 count 查询。
第二个瓶颈是深分页。我之前已经改成游标分页，但通知列表查询条件里 if 条件过多，比如用户选择了只看维修通知，过滤条件用不上索引。我在 notice_id、publish_time 上建了联合索引，并让前端筛选类型时直接通过正排索引先过滤，然后再走游标排序。优化后接口 P95 响应时间从 800ms 降到了 120ms 左右。
5.6 富文本内容安全：防止学生端被注入
通知内容由宿管人员在后台录入，看起来不值得担心安全问题，但宿管经常从 Word、网页上复制内容，这些内容里可能带着隐藏的脚本片段或危险标签。如果管理端不处理，直接入库，再通过学生端 v-html 渲染，恶意代码是完全有可能被执行的。
我在后端统一接入了 HTML 白名单清洗策略。用 Jsoup 的 Cleaner 配合 Safelist，只允许保留 p、br、strong、span、img 等标签，去掉 script、iframe、style、事件属性和 javascript 伪协议。
java复制private String sanitizeHtml(String rawHtml) {
Safelist safelist = Safelist.relaxed()
.removeTags("script", "iframe", "object", "embed")
.removeAttributes("img", "onerror", "onclick");
return Jsoup.clean(rawHtml, safelist);
}
富文本清洗必须在服务端做，不能依赖前端过滤。前端过滤只是体验层面的处理，所有内容进数据库之前都应该在服务端再清洗一遍。学生端收到详情内容后，渲染前也建议使用白名单方案再做一次轻量过滤。
6. 上线后的真实运营数据与经验沉淀
DormMate 通知公告模块上线使用了一个完整学期，我拿到了一些很直观的运营数据，可以给大家做个参考。接入这个模块后，宿管老师每天平均发送通知 12 条，紧急通知占比从最初的不超过 5% 慢慢回归正常；学生端通知的 24 小时已读率稳定在 86% 左右，加急短信兜底触发后能达到 95% 以上。
让我印象最深的不是这些漂亮数据，而是一个很不起眼的场景：有位宿管老师第一次在后台看到“未读名单”时跟我说，以前要拿着打印好的通知一层楼一层楼去敲门确认，现在系统告诉她 3 栋 402 的小王到现在还没看那条晚上停水的通知，她只需要专门给那一个宿舍提个醒就够了。这就是通知公告模块的价值：它不是做了个花哨的推送工具，而是把宿管从“广播式通知”变成了“可追踪、可兜底、可负责”的精准触达。
如果你也要做类似的宿舍管理系统通知模块，我最后想给的三个建议是：把通知、接收范围、已读记录三张表拆干净，宁可多写点代码也千万别为了省事合并成一张大宽表；推送、短信、WebSocket 都只能是提醒手段，唯一的真相来源是数据库里的记录；先做核心闭环，再做花哨功能，宿管真正需要的永远是“把话说清楚，并且知道谁没听清”。
这轮开发做完后，我最大的体会是：很多看起来“很简单”的模块，只有真正放进真实业务里跑一遍，才会发现它牵扯到的状态机、并发、安全、时效性处理一点都不能含糊。希望这篇 DormMate 通知公告模块的实战复盘，能帮你把自己的通知模块做得少一点坑、多一点掌控感。