半泽和莉娜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，正常宿舍通知很少会超过几万字，这个容量完全够