校园通衢公告枢纽系统
基于 Spring Boot + Vue 3 的校园公告管理系统的设计与实现
目录
- 一、开发背景与目的
- [1.1 开发背景](#1.1 开发背景)
- [1.2 开发目的](#1.2 开发目的)
- 二、技术架构
- [2.1 技术选型](#2.1 技术选型)
- [2.2 系统架构图](#2.2 系统架构图)
- [2.3 项目目录结构](#2.3 项目目录结构)
- 三、数据库设计
- [3.1 E-R 关系图](#3.1 E-R 关系图)
- [3.2 核心表说明](#3.2 核心表说明)
- 四、业务逻辑
- [4.1 角色权限体系](#4.1 角色权限体系)
- [4.2 认证与鉴权流程](#4.2 认证与鉴权流程)
- [4.3 公告生命周期](#4.3 公告生命周期)
- [4.4 推送通知机制](#4.4 推送通知机制)
- [4.5 统计分析](#4.5 统计分析)
- 五、主要页面说明
- [5.1 登录页](#5.1 登录页)
- [5.2 公告列表（首页）](#5.2 公告列表（首页）)
- [5.3 公告详情页](#5.3 公告详情页)
- [5.4 公告编辑页](#5.4 公告编辑页)
- [5.5 公告审核页](#5.5 公告审核页)
- [5.6 统计分析页](#5.6 统计分析页)
- [5.7 用户管理页](#5.7 用户管理页)
- [5.8 分类管理页](#5.8 分类管理页)
- [5.9 个人中心](#5.9 个人中心)
- 六、接口设计
- 七、部署方案
- [7.1 Docker 容器化部署](#7.1 Docker 容器化部署)
- [7.2 一键启动](#7.2 一键启动)
- 八、总结与展望
- [8.1 项目总结](#8.1 项目总结)
- [8.2 未来展望](#8.2 未来展望)
一、开发背景与目的
1.1 开发背景
在高校日常管理中，公告通知是信息传递的重要手段。然而，传统的公告发布方式（如张贴纸质通知、微信群转发等）普遍存在以下问题：
- 信息传递效率低：纸质公告覆盖范围有限，容易遗漏；群消息易被刷屏淹没。
- 缺乏审核机制：公告内容未经审核直接发布，可能出现信息不准确、格式不规范等问题。
- 无法追踪阅读情况：管理者无从得知通知是否被目标群体有效接收。
- 信息难以归档：历史公告散落在不同平台，查找和管理困难。
随着高校信息化建设的推进，亟需一套集公告发布、分类管理、审核流程、消息推送、阅读统计于一体的数字化公告管理平台。
1.2 开发目的
本系统旨在为高校提供一个统一、高效、可追溯的公告管理平台，主要目标包括：
- 规范公告发布流程：建立"草稿 → 审核 → 发布"的标准化工作流，确保公告内容质量。
- 提升信息触达效率：公告审核通过后自动推送至全体用户，支持站内通知提醒。
- 实现阅读追踪：记录每位用户的阅读行为，为管理者提供数据支撑。
- 支持多角色协作：管理员统筹管理，教师发布公告，学生查阅信息，各司其职。
- 提供数据分析能力：通过统计看板直观展示公告数据趋势，辅助决策。
二、技术架构
2.1 技术选型
| 层次 | 技术 | 版本 | 说明 |
|---|---|---|---|
| 后端框架 | Spring Boot | 3.4.5 | 自动配置、内置 Tomcat，快速构建 REST 服务 |
| 持久层 | MyBatis-Plus | 3.5.7 | 内置 CRUD、分页插件、逻辑删除，减少样板代码 |
| 安全框架 | Spring Security + JWT | --- | RBAC 角色权限控制，无状态 Token 认证 |
| 前端框架 | Vue 3 | 3.5 | Composition API，前后端分离 |
| UI 组件库 | Element Plus | 2.9 | 企业级 Vue 3 组件库 |
| 状态管理 | Pinia | 2.3 | Vue 3 官方推荐状态管理方案 |
| 数据可视化 | ECharts | 5.5 | 统计图表渲染 |
| 构建工具 | Vite | 6.0 | 极速开发构建 |
| 数据库 | MySQL | 8.0 | 关系型数据存储 |
| 容器化 | Docker + Docker Compose | --- | 一键部署前后端服务 |
2.2 系统架构图
┌───────────────────────────────────────────────────────┐
│ 用户浏览器 │
└───────────────────────┬───────────────────────────────┘
│ HTTP
┌───────────────────────▼───────────────────────────────┐
│ Nginx (前端服务) │
│ Vue 3 + Element Plus + ECharts │
│ ┌──────────┬──────────┬──────────┬──────────┐ │
│ │ 路由守卫 │ Pinia │ Axios │ 页面组件 │ │
│ └──────────┴──────────┴──────────┴──────────┘ │
└───────────────────────┬───────────────────────────────┘
│ /api/* 反向代理
┌───────────────────────▼───────────────────────────────┐
│ Spring Boot (后端服务) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Security Filter Chain → JWT 认证 → 角色鉴权 │ │
│ ├─────────────────────────────────────────────────┤ │
│ │ Controller（表现层） │ │
│ ├─────────────────────────────────────────────────┤ │
│ │ Service（业务逻辑层） │ │
│ ├─────────────────────────────────────────────────┤ │
│ │ MyBatis-Plus Mapper（数据访问层） │ │
│ └──────────────────────┬──────────────────────────┘ │
└─────────────────────────┼─────────────────────────────┘
│ JDBC
┌─────────────────────────▼─────────────────────────────┐
│ MySQL 数据库 │
│ tb_user / tb_role / tb_announcement / tb_category │
│ tb_attachment / tb_push_record / ... │
└───────────────────────────────────────────────────────┘2.3 项目目录结构
gonggao/
├── src/main/java/com/xiaoa/gonggao/
│ ├── controller/ # REST 接口（7个控制器 + 健康检查）
│ ├── service/ # 业务接口
│ │ └── impl/ # 业务实现
│ ├── mapper/ # MyBatis-Plus 数据访问（8个 Mapper）
│ ├── entity/ # 数据库实体类（8个实体）
│ ├── dto/ # 请求数据传输对象
│ ├── vo/ # 响应视图对象
│ ├── config/ # 配置类（Security、CORS、MyBatis-Plus）
│ ├── security/ # JWT 过滤器、认证用户封装
│ └── utils/ # 工具类（JWT 工具）
├── src/main/resources/
│ ├── application.yaml # 应用配置
│ └── sql/ # 数据库脚本
├── frontend/ # Vue 3 前端工程
│ ├── src/views/ # 页面组件（10个视图）
│ ├── src/api/ # 接口请求模块（6个模块）
│ ├── src/router/ # 路由配置（含权限守卫）
│ ├── src/stores/ # Pinia 状态管理
│ └── src/utils/ # Axios 封装
├── Dockerfile # 后端多阶段构建
├── frontend/Dockerfile # 前端多阶段构建
└── docker-compose.yml # 容器编排三、数据库设计
3.1 E-R 关系图
┌──────────┐ N:N ┌──────────┐
│ tb_user │◄──────────►│ tb_role │
└────┬─────┘ └──────────┘
│ 通过 tb_user_role 关联
│
│ 1:N (发布)
▼
┌──────────────────┐ N:1 ┌──────────────┐
│ tb_announcement │◄─────────►│ tb_category │
└───┬──────┬───────┘ └──────────────┘
│ │
│ │ 1:N
│ ▼
│ ┌──────────────┐
│ │ tb_attachment │
│ └──────────────┘
│
│ 1:N 1:N
├───────────────┐
▼ ▼
┌────────────────┐ ┌────────────────┐
│ tb_announce- │ │ tb_push_record │
│ ment_read │ └────────────────┘
└────────────────┘3.2 核心表说明
| 表名 | 说明 | 关键字段 |
|---|---|---|
tb_user |
用户表 | username, password(BCrypt), realName, status |
tb_role |
角色表 | roleName, roleKey(ADMIN/TEACHER/STUDENT) |
tb_user_role |
用户角色关联 | userId, roleId（多对多） |
tb_category |
公告分类 | categoryName, sortOrder |
tb_announcement |
公告表 | title, content, status(0~3), publisherId, reviewerId |
tb_announcement_read |
阅读记录 | announcementId, userId, readTime |
tb_attachment |
附件表 | announcementId, fileName, filePath, fileSize |
tb_push_record |
推送记录 | announcementId, targetUserId, isRead |
所有业务表均支持逻辑删除 （deleted 字段）和自动时间戳（createTime, updateTime）。
四、业务逻辑
4.1 角色权限体系
系统采用 RBAC（基于角色的访问控制）模型，定义三类角色：
| 功能模块 | 管理员（ADMIN） | 教师（TEACHER） | 学生（STUDENT） |
|---|---|---|---|
| 查看公告列表与详情 | ✅ | ✅ | ✅ |
| 创建/编辑公告 | ✅ | ✅ | ❌ |
| 提交公告审核 | ✅ | ✅ | ❌ |
| 审核公告（通过/驳回） | ✅ | ❌ | ❌ |
| 用户管理（增删改查） | ✅ | ❌ | ❌ |
| 分类管理 | ✅ | ❌ | ❌ |
| 统计分析 | ✅ | ✅ | ❌ |
| 上传附件 | ✅ | ✅ | ❌ |
| 接收通知 | ✅ | ✅ | ✅ |
4.2 认证与鉴权流程
用户登录
│
▼
POST /api/auth/login（用户名 + 密码）
│
▼
后端校验密码（BCrypt）
│
├─ 失败 → 返回 401
│
▼ 成功
生成 JWT Token（含 userId, username, roleKey）
│
▼
前端存储 Token 至 localStorage
│
▼
后续请求携带 Authorization: Bearer <token>
│
▼
JwtAuthenticationFilter 拦截 → 解析 Token → 注入 SecurityContext
│
▼
@PreAuthorize 注解校验角色权限4.3 公告生命周期
公告从创建到展示经历完整的状态流转：
┌─────────┐ 提交审核 ┌─────────┐
│ 草稿(0) │ ───────────────► │ 待审核(1) │
└─────────┘ └────┬────┘
▲ │
│ 管理员审核 │
│ ┌──────────────┼──────────────┐
│ ▼ ▼
│ ┌──────────┐ ┌──────────┐
│ │ 已发布(2) │ │ 已驳回(3) │
│ └────┬─────┘ └────┬─────┘
│ │ │
│ │ 自动推送通知 │ 可修改后
│ ▼ 至全体用户 │ 重新提交
│ ┌──────────┐ │
│ │ 用户查阅 │ │
│ │ 记录阅读 │ │
│ └──────────┘ │
└──────────────────────────────────────────┘关键业务规则：
- 创建公告：教师或管理员填写标题、正文、分类、过期时间等信息，初始状态为草稿。
- 提交审核：将草稿状态(0)变更为待审核(1)，等待管理员处理。
- 审核公告 ：管理员对待审核公告进行审批：
- 通过：状态变为已发布(2)，记录发布时间和审核人，自动触发全员推送。
- 驳回：状态变为已驳回(3)，填写驳回原因，发布者可修改后重新提交。
- 阅读追踪：用户首次查看公告时记录阅读记录，同一用户同一公告不重复记录。
- 推送通知：审核通过后，系统自动为除发布者外的所有启用状态用户创建推送记录。
4.4 推送通知机制
公告审核通过
│
▼
查询所有 status=1 的用户（排除发布者）
│
▼
为每位用户创建 PushRecord（isRead=0）
│
▼
前端轮询未读通知数量 → 显示在顶部导航栏徽标
│
▼
用户点击通知 → 标记为已读（isRead=1, 记录 readTime）4.5 统计分析
系统提供以下统计维度：
- 总览数据：公告总数、用户总数、总阅读量、今日新增公告数
- 分类分布：各分类下公告数量（饼图/柱状图展示）
- 发布趋势：近 N 天每日公告发布数量（折线图展示）
五、主要页面说明
5.1 登录页
用户输入用户名和密码进行身份认证，登录成功后根据角色跳转至首页。默认管理员账号：admin / admin123。
5.2 公告列表（首页）
所有角色可见。展示已发布公告的分页列表，支持按分类筛选和关键词搜索。置顶公告优先展示。
5.3 公告详情页
展示公告完整内容，包括标题、正文、发布人、发布时间、分类、附件下载链接。进入详情页时自动记录阅读并累加阅读计数。
5.4 公告编辑页
教师和管理员可用。提供富文本编辑器编写公告正文，设置分类、过期时间、是否置顶，支持上传附件。可保存为草稿或直接提交审核。
5.5 公告审核页
仅管理员可见。展示所有待审核公告列表，管理员可查看详情后选择通过或驳回（驳回需填写原因）。
5.6 统计分析页
管理员和教师可见。通过 ECharts 图表展示公告总览数据、分类分布、发布趋势。
5.7 用户管理页
仅管理员可见。支持用户的增删改查、角色分配、账号启用/禁用。
5.8 分类管理页
仅管理员可见。管理公告分类的增删改查和排序。
5.9 个人中心
所有角色可见。展示当前用户信息，查看站内通知消息列表，支持标记已读。
六、接口设计
系统采用 RESTful 风格 API，统一响应格式：
json
{
"code": 200,
"message": "操作成功",
"data": { }
}主要接口列表
| 模块 | 方法 | 路径 | 说明 | 权限 |
|---|---|---|---|---|
| 健康检查 | GET | /api/health |
服务健康状态 | 公开 |
| 认证 | POST | /api/auth/login |
用户登录 | 公开 |
| 认证 | POST | /api/auth/logout |
用户登出 | 登录用户 |
| 认证 | GET | /api/auth/info |
获取当前用户信息 | 登录用户 |
| 公告 | GET | /api/announcements |
公告分页列表 | 登录用户 |
| 公告 | GET | /api/announcements/{id} |
公告详情 | 登录用户 |
| 公告 | POST | /api/announcements |
创建公告 | 管理员/教师 |
| 公告 | PUT | /api/announcements/{id} |
更新公告 | 管理员/教师 |
| 公告 | DELETE | /api/announcements/{id} |
删除公告 | 管理员/教师 |
| 公告 | PUT | /api/announcements/{id}/submit |
提交审核 | 管理员/教师 |
| 公告 | PUT | /api/announcements/{id}/review |
审核公告 | 管理员 |
| 分类 | GET | /api/categories |
分类列表 | 登录用户 |
| 分类 | POST | /api/categories |
创建分类 | 管理员 |
| 分类 | PUT | /api/categories/{id} |
更新分类 | 管理员 |
| 分类 | DELETE | /api/categories/{id} |
删除分类 | 管理员 |
| 用户 | GET | /api/users |
用户分页列表 | 管理员 |
| 用户 | POST | /api/users |
创建用户 | 管理员 |
| 用户 | PUT | /api/users/{id} |
更新用户 | 管理员 |
| 用户 | DELETE | /api/users/{id} |
删除用户 | 管理员 |
| 附件 | POST | /api/attachments/upload |
上传附件 | 管理员/教师 |
| 附件 | GET | /api/attachments/{id} |
下载附件 | 登录用户 |
| 推送 | GET | /api/push/notifications |
我的通知列表 | 登录用户 |
| 推送 | PUT | /api/push/{id}/read |
标记通知已读 | 登录用户 |
| 推送 | GET | /api/push/unread-count |
未读通知数 | 登录用户 |
| 统计 | GET | /api/statistics/overview |
统计总览 | 管理员/教师 |
| 统计 | GET | /api/statistics/trend |
发布趋势 | 管理员/教师 |
七、部署方案
7.1 Docker 容器化部署
项目采用 Docker Compose 编排，前后端均使用多阶段构建：
┌──────────────────────────────────────────┐
│ Docker Compose │
│ │
│ ┌────────────────┐ ┌────────────────┐ │
│ │ gonggao │ │ gonggao-ui │ │
│ │ (backend) │ │ (frontend) │ │
│ │ :8088 │ │ Nginx :80 │ │
│ └───────┬────────┘ └───────┬────────┘ │
│ │ │ │
│ │ 端口 3004 映射 │ │
└──────────┼───────────────────┼────────────┘
│ │
┌──────▼──────┐ │
│ MySQL │◄───────────┘
│ 8.146.211.92 │ /api/* 反向代理至 backend
└─────────────┘7.2 一键启动
bash
# 构建并启动
docker compose up -d --build
# 查看服务状态
docker compose ps
# 查看日志
docker compose logs -f启动后访问：http://<服务器IP>:3004
八、总结与展望
8.1 项目总结
本系统实现了校园公告管理的核心功能闭环：
- 完整的公告生命周期管理：从草稿创建、提交审核、管理员审批到正式发布，建立了规范化的公告发布流程。
- 基于角色的权限控制：通过 Spring Security + JWT 实现了管理员、教师、学生三级角色体系，各角色权责分明。
- 消息推送与阅读追踪：公告发布后自动推送通知，并精确记录每位用户的阅读行为，为管理决策提供数据支撑。
- 数据可视化统计：通过 ECharts 图表直观展示公告运营数据，辅助管理者掌握信息传播效果。
- 容器化部署：采用 Docker 多阶段构建 + Docker Compose 编排，实现一键部署。
8.2 未来展望
- 移动端适配：开发小程序或移动端 H5 页面，方便师生随时随地查看公告。
- 精准推送：支持按学院、班级、年级等维度精准推送，而非全员推送。
- 富媒体内容：支持公告内嵌视频、音频等多媒体内容。
- 全文检索：接入 Elasticsearch，实现公告内容的全文搜索。
- 邮件/短信通知：对接邮件和短信服务，实现多渠道通知触达。
- 公告模板：提供常用公告模板，提高发布效率。
- 数据导出：支持公告数据和统计报表导出为 Excel/PDF。
- WebSocket 实时推送：替换前端轮询方案，实现通知的实时推送。