做传媒公司行政管理系统这类项目最容易被忽视的反而是动手前的业务梳理。代码可以一周写完表结构也能很快定下来可要是业务边界没想清楚后面每一轮改动都在还债。我最近完整复盘了一遍这套基于Spring Boot的传媒公司行政管理系统从数据库脚本、后端接口、前端页面到配套的万字论文算是一次比较彻底的整理。这篇文章就把整个项目的设计逻辑、落地过程和运行经验拆开来讲适合正在做毕业设计、准备拿源码二次开发或者想快速搭一套内部管理后台的同学参考。1. 传媒公司行政管理系统到底要管什么1.1 先理清业务边界一套系统解决哪些行政痛点我接手这类系统时第一件事从来不是建表而是搞清楚行政人员每天都在处理什么。传媒公司的行政部门和其他行业有个明显区别业务节奏快、项目制明显、临时人员多。今天要协调演播室档期明天要安排外拍车辆还要盯着摄像机、灯光、收音设备这种高价值资产的流向。人员入离职频繁设备借还频繁会议室冲突是常态用车申请往往要跟项目时间赛跑。如果线下用Excel管这些事最大的问题是信息割裂。设备借给谁了、会议室哪个时段被人占了、车钥匙在谁手里全靠口头问。行政系统要解决的核心痛点就三句话资源可查、流程可追、记录可溯。所以系统第一优先级不是界面好看而是把人、事、物、流程四条线全部数字化。在这个项目里我把它拆成了四大类人力基础部门、岗位、员工档案、账号信息行政资源固定资产、办公用品、会议室、车辆业务流程请假审批、用车申请、会议室预约、用品申领信息触达公告发布、待办提醒、操作日志。这套边界定下来之后后面所有功能模块都围绕这四个方向展开不会跑偏论文的第三章系统分析也有现成的素材。1.2 传媒行业的特殊需求会议室、车辆与设备流转普通企业的行政系统管会议室和办公用品就够了但传媒公司还要额外关注三个特殊场景会议室的本质是档期资源。它不只是一个空房间而对应着节目录制、项目组讨论、客户提案等具体业务预约时必须按时间段锁定否则两个栏目组同时要用演播室就是事故。车辆调度的核心是出勤时效。外拍车、转播车都有任务时间窗口审批不能拖太久所以我在设计车辆申请流程时特意区分了部门审批和车辆管理员派车两个环节早一点把时间自由度给到使用者。设备资产的重点是借还闭环。一台摄像机可能值几十万从哪个项目组借走、什么时候归还、有没有损坏必须有一条完整的记录。普通企业的固定资产只需要登记流向传媒公司则更需要把借用记录作为核心数据维护起来。想清楚这些再去写代码每一张表的存在意义都很明确不会出现那种为凑功能而硬凑出来的废表。2. Spring Boot技术选型为什么这套栈最适合这类管理系统2.1 后端框架选型的核心诉求选 Spring Boot 不是因为它时髦而是这类管理系统对技术栈的要求恰好和它匹配到一块了。首先是交付效率。管理系统有大量重复的增删改查Spring Boot 配合 MyBatis-Plus单表 CRUD 几乎不用写 SQLBaseMapper 直接把方法给你备好了。我说得直白点这套系统的价值在于业务关系的梳理而不是每天手写一百行重复的数据库操作。其次是部署友好。Spring Boot 内置 Tomcat打包成 jar 之后一条命令就能跑起来不用单独配 Web 服务器。这对本地调试和服务器部署都很省事尤其是学生做毕设时演示环境一台笔记本就搞定不依赖复杂的生产环境。第三是排错成本低。Spring Boot 的资料和案例到处都是遇到问题搜一下基本都有答案。对于个人开发者和学生来说这比选一个小众框架稳得多。技术选型最怕的不是不够高级而是出了问题没人能帮你看。在具体版本上我习惯用 Spring Boot 2.7.x 搭配 JDK 8这个组合兼容性好依赖也稳定。如果你用 3.x 版本就要注意 JDK 版本升到 17MyBatis-Plus 和相关驱动也要用对应的新版本不然启动时会踩不少坑。2.2 前端方案与权限管理思路这套系统的前端我推荐用 Vue 加 Element Plus 做后台管理界面再配合 Axios 调接口。管理后台的特点是表单多、表格多、交互模式固定Element Plus 已经把这些组件都封装好了你不用自己造轮子页面做出来也挺工整。权限认证用的是 Spring Security 加 JWT。Spring Security 负责拦截请求、校验身份JWT 负责在无状态环境下保存登录凭证。前端登录成功拿到 token后续请求都带着这个 token后端通过过滤器解析 token 得到用户身份再去查角色和菜单权限。这套组合在前后端分离的小型系统里非常适合一是部署简单不依赖 Session 共享二是接口结构清晰移动端将来要对接也方便。如果项目用的是 Thymeleaf 做服务端渲染权限控制会更简单直接靠 Spring Security 的注解控制页面访问权限就行。但这个项目我推荐前后端分离系统界面的操作体验更流畅论文里写系统架构时也能多出前后端交互的层次感。3. 数据库模型行政系统的主干表与关联关系3.1 核心表结构与字段要点我建表有个习惯先把主体表列出来再画关系最后才动 SQL。这套系统的核心表大概有十五张左右我用下面这个表概述一下表名用途关键说明sys_user系统账号表存登录账号、密码、状态sys_role角色表管理员、行政人员、普通员工sys_menu菜单权限表构建前端菜单树sys_role_menu角色菜单关联表多对多关系department部门表传媒公司常按栏目或项目组划分staff_info员工档案表姓名、岗位、入职时间、联系方式notice公告表标题、内容、发布人、发布时间notice_read公告已读表记录哪些人已经看过meeting_room会议室表座位数、设备、位置meeting_reservation会议室预约表预约人、时段、用途、状态vehicle车辆表车牌、车型、座位数、状态vehicle_application车辆申请记录表用车人、时间、目的地、审批状态assets固定资产表资产编号、类别、使用人supplies_claim办公用品申领记录表申领人、物品、数量、时间leave_record请假记录表请假类型、起止时间、审批状态operation_log操作日志表操作人、操作类型、详情、时间这几张表之间最重要的是两个关系用户和角色、申请和审批。用户和角色通过 sys_role_menu 和 sys_user_role 这类关联表连接形成标准的 RBAC 模型。我建议不要在设计时把权限直接硬编码到用户表里头不然加角色和调权限的时候会非常痛苦。申请与审批的关联是这个系统的落点。会议室预约、车辆申请、请假记录、用品申领这些表本质上是同一类模式业务表加上一个状态字段再关联一条流程记录。用统一的处理逻辑去处理代码量会少很多后面我单独说状态机。3.2 状态机设计审批流如何落库审批类功能是整个行政系统里最容易写乱的模块。很多初次做这种项目的人会把审批状态放在业务表里然后用一个 if-else 把所有逻辑串起来后面加审批层级就崩溃。我的做法是给每张业务表设计一个 status 字段取值统一规范一下状态值含义说明0草稿已填写未提交1待审批已提交等审批人处理2已通过审批通过可进入执行阶段3已驳回审批不通过可修改后重新提交4已撤销申请人自己取消如果系统是单级审批表里加一个 approver_id 字段就够了。若是多级审批建议加一张审批流程记录表用申请单号关联每一级审批都往里面插一条记录审批人、审批时间、结果、意见。这样往上加审批层级不需要改业务表结构只需要往流程记录表里插数据。这里有个细节值得注意会议室预约和车辆申请在审批通过后还有使用中已完成这类执行状态不要和审批状态混在一起写。我习惯额外维护一个执行状态字段或者用不同的状态值区间区分避免把审批流程和业务生命周期搅成一锅粥。数据库的冗余我也提一句。像车辆申请这种场景后端接口返回给前端的时候最好直接带上司机姓名、部门名称这些冗余字段前端不用再发二次请求。MyBatis-Plus 里可以用关联查询或者在 VO 层做聚合这个在设计阶段就考虑好后面写接口效率会高很多。4. 核心功能模块的实现逻辑与权限控制4.1 登录认证与RBAC权限控制登录模块看起来简单实际是后端代码最先要写对的地方。我用 JWT 做登录态管理基本流程是用户提交账号密码后端校验通过后生成 token 返回给前端前端把 token 存在本地每次请求带上。后端用一个过滤器拦截所有请求先解析 token再根据用户 ID 去查当前用户的角色和权限列表。权限控制不要写死在代码里要走数据库配置。菜单表里每个菜单项记录对应的权限标识角色表关联菜单用户表关联角色。这样将来要给某个角色新增权限时只需要在后台的数据字典里配一下不用改代码重新部署。Spring Security 的配置里最关键的是放行规则。登录接口、获取验证码这类接口要放行其他接口一律需要认证同时配置跨域支持。开发时容易遇到的一个问题是前端请求提示 401 或者跨域报错八成是过滤器链的顺序没排对或者跨域配置被安全拦截规则优先级覆盖了。4.2 会议室预约的冲突校验会议室预约能体现一个系统细节是否到位。我刚看到有些实现时很意外——需求方只在同一天同一房间的维度上判断冲突结果出现上午 9 点到 11 点和上午 10 点到 12 点的预约同时存在也不报错。这显然不对。正确的冲突判断是时间区间重叠判断。假设已有一场预约的时间是 [startA, endA]新预约的时间是 [startB, endB]两边互斥的条件是新预约开始时间早于已有预约结束时间并且新预约结束时间晚于已有预约开始时间用 SQL 写就是SELECT COUNT(*) FROM meeting_reservation WHERE room_id #{roomId} AND status IN (1, 2) AND start_time #{endTime} AND end_time #{startTime};这个查询返回条数大于 0就说明这段时间已经有预约了直接提示冲突。我在实际测试中也遇到一些很容易被忽略的边界例如传入的时间是 14:00 到 15:00已有的预约是 14:30 到 14:45这种包含关系仍然会被上面的查询识别出来。预约模块还有一个优化点如果会议室数量多可以把日期字段单独建索引避免每次查询都把整张表扫一遍。数据量不大时不明显一旦积累了一年以上的预约记录性能差距就能感觉到。4.3 车辆调度与审批链车辆申请模块我拆成了两个阶段审批和派车。申请人提交用车申请填写用车时间、目的地、人数、车型偏好领导审批通过后由车辆管理员或者司机在实际执行时标记已出车已还车。这样既满足流程控制又保留了一定的线下灵活性。车辆表里要维护的基本字段包括车牌号、车辆类型、座位数、驾驶员、车辆状态。车辆状态我用几个离散值来表示空闲、使用中、维修中。申请时优先展示空闲车辆实际调度时可以人工指定哪辆车。审批链的设计上这个系统走的是单级审批流程请假、用车、用品申领都是同一个模式用户提交申请管理员审批结果通过站内通知反馈给申请人。如果你希望做二级审批比如用车先部门审批、再行政审批那就把前面说的审批流程记录表用起来每一级记录一条状态流转的判断也统一收敛到 Service 层的一个方法里不要散落在 Controller 各处。4.4 公告、待办与操作日志公告功能看着简单但有一处容易漏掉——已读状态。一篇文章发出来后后台期望看到哪些人读了、哪些人还没读这需要一张独立的公告已读表用公告ID加用户ID做联合主键。用户打开公告详情的时候插入一条已读记录统计时直接查这张表聚合。待办提醒表面上只是展示当前用户待审批的申请数量但它是系统的使用黏性来源之一。员工提交申请后审批人登录系统第一时间能看到待办数量行政办公的效率感就出来了。实现上不复杂后端提供一个待办统计接口前端在导航栏上显示角标数字就行。操作日志用 AOP 注解去做最优雅。我写了一个 Log 注解标记在 Controller 方法上通过 AOP 切面拦截请求把操作人、操作类型、参数信息和执行时间插入日志表。这样不用在每个方法里重复写日志代码审计功能就齐了。选题时写论文操作日志这块也很适合放进系统安全性与可靠性的章节里展开。5. 从数据库脚本到页面跑通完整部署调试流程5.1 环境准备清单拿到项目的源码加数据库脚本之后环境对不齐是第一个坑。我列一下这套环境的版本建议照着配基本不会出问题工具建议版本用途JDK1.8 或 17运行后端服务Maven3.6 及以上管理后端依赖MySQL5.7 或 8.0数据存储Node.js16 及以上前端依赖安装与构建IDEA2022 及以上开发调试 IDE我建议用 IDEA 打开后端目录用 VS Code 或 IDEA 打开前端目录两边分开跑不然两个项目堆在同一个窗口里看日志很混乱。数据库工具可以用 Navicat 或 DataGrip导入脚本的时候直接执行整个 .sql 文件。5.2 启动步骤与关键配置后端启动前最重要的一步是修改数据库连接配置。打开 application.yml把 MySQL 的地址、账号、密码改成你自己的spring: datasource: url: jdbc:mysql://localhost:3306/admin_system?serverTimezoneAsia/ShanghaiuseUnicodetruecharacterEncodingutf8 username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver这里我特别强调一下 serverTimezoneAsia/Shanghai很多人在 MySQL 8 下启动报错都是因为没有配置时区。然后按顺序来在数据库里新建一个空白库名字和配置里的库名保持一致用 Navicat 或命令行导入项目自带的 .sql 脚本先启动后端 Spring Boot 主类看到 Tomcat started 的日志说明后端起来了再进前端目录执行 npm install 安装依赖然后 npm run dev 启动浏览器访问前端地址用管理员账号登录。如果脚本里建过库执行时要注意选择正确的目标库。命令行导入的方式是mysql -u root -p admin_system admin_system.sql前提是库已经建好。5.3 常见报错排查表我把实际运行中高频出现的报错和处理方式汇总成一个表照着排查比较快报错现象根本原因解决办法后端启动时连不上数据库MySQL 服务没开或账号密码错误检查 MySQL 服务核对 yml 配置Access denied for user数据库用户权限不足给 root 或当前用户开远程/本地权限前端请求接口 404后端地址或端口不对检查前端请求的 baseURL 是否指向 8080前端请求接口跨域前后端分离未配置跨域后端加跨域配置类或用前端代理端口被占用8080 被其他程序占用换端口或用命令杀掉占用进程Maven 下载依赖卡住默认源下载慢换成国内镜像源再重新导入页面表格加载不出数据权限不足或 token 失效清空本地 token 重新登录调试时我习惯先把后端接口调通用浏览器直接访问一个接口地址确认返回 JSON 后再调前端页面。这样可以减少前后端同时出问题的排查范围效率最高。6. 拿到源码之后如何快速读懂并做二次开发6.1 代码目录结构先看哪里、后看哪里如果你拿到的是一份完整的项目源码几千个文件摆在那别急着到处点。我自己的阅读顺序是先看数据库脚本再看后端代码结构最后看前端页面。后端最核心的目录就几个controller 层看有哪些接口理解每个功能模块对外暴露了什么service 层看业务逻辑尤其审批状态流转都在这层mapper 层看数据库操作如果用了 MyBatis-Plus大部分只是继承 BaseMapperentity 层看实体对应哪些数据库表config 层看安全配置、跨域配置理解系统的基础拦截逻辑。前端结构对应后端模块views 目录下面按功能模块分文件夹router 里配置页面路由store 里管理登录状态和用户信息。二开之前最好先把管理员登录到系统里逐个功能点击一遍对照前端页面、接口和表结构把一条完整链路摸清楚。这个动作花半天时间后面改代码能省三天时间。6.2 最常见的三类二开需求我刚接触这类系统时边上同学问得最多的二开需求翻来覆去无非三类加字段、改审批、加导出。这三类我都说下常规做法。加字段是最常见的。例如员工档案里要增加紧急联系人字段需要动三个地方数据库表加一列实体类和 VO 加属性前端列表和表单加输入项。数据库先执行 ALTER TABLE 语句然后顺着 entity-前端 的顺序同步改完重启验证即可。改审批流程稍微麻烦。如果要做二级审批先看现有业务表的 status 字段增加中间态再找到 Service 层的审批方法在驳回和通过的分支上加状态判断最后把审批流程记录表关联进去。核心原则是先改状态机再改接口最后改前端按钮显示逻辑。加导出功能建议直接用 EasyExcel。用法就是把查询列表转换成 Excel 文件流输出几十行业务代码就能搞定比 POI 自己写要快得多样式也好看。放在论文的系统实现章节里也很适合截图当亮点。7. 配套论文与结题文档的写作思路7.1 万字论文的骨架怎么搭这篇配套论文能写到一万字以上其实不用怕凑字数关键是骨架要对。我推荐的论文结构是标准的信息管理系统六章法第一章 绪论写研究背景、国内外现状、研究内容与意义第二章 相关技术介绍Spring Boot、Vue、MySQL 等第三章 系统分析可行性分析、功能性需求、非功能性需求第四章 系统设计总体架构、功能模块设计、数据库设计第五章 系统实现核心模块界面与关键代码第六章 系统测试测试用例、结果分析。写的时候有一个技巧把重心放在第三章和第四章这两章是评委最看重的部分。需求分析要写具体使用场景和用例数据库设计要画 E-R 图并逐表说明字段含义这两个章节细腻展开就能占到四千字以上。系统实现部分不要每页都截一大堆代码选三四个核心模块每个模块放关键代码片段和运行界面截图加上一段文字说明即可。测试章节设计十来个用例表覆盖登录、权限、会议室冲突、车辆审批等场景表格列清楚输入、预期结果、实际结果这个测试章节看着就很扎实。7.2 系统测试章节怎么写才有说服力很多学生的论文测试部分写成了流水账一条一条列功能正常。我建议按功能模块分组写每组给一个测试用例表格至少包含用例编号、测试项目、前置条件、操作步骤、预期结果、实际结果。比如会议室模块的测试用例正常预约、时间冲突提示、跨日期预约、状态为审批中时不能再被占用这四条写进表格逻辑覆盖很完整比空写测试通过有说服力得多。非功能性测试可以写响应时间、并发操作、浏览器兼容性用 Chrom 和 Edge 各测一遍截图这部分也算差异化亮点。测试不要求自动化。这类管理系统用黑盒手动测试就能撑起整个章节重点是把每个模块的综合场景覆盖到边测边记录最后整理成表格写作效率会非常高。个人习惯是画完数据库 E-R 图再写测试用例因为测试本质上也是对着流程走一遍。系统跑通之后我最大的体会是这类管理系统的真正难点不在技术上而在状态流转的完整性和数据边界的合理性上。把审批状态机设计清楚把会议室冲突判断做严谨把操作日志铺到位剩下的功能模块都会变成流水线式的体力活。如果你准备开题或者正在改代码建议先花一个晚上把表结构和状态枚举图画出来再碰具体的业务代码后面至少能少熬三个通宵。