企业官网建设流程全解析

做传媒公司行政管理系统这类项目，最容易被忽视的反而是动手前的业务梳理。代码可以一周写完，表结构也能很快定下来，可要是业务边界没想清楚，后面每一轮改动都在还债。我最近完整复盘了一遍这套基于Spring Boot的传媒公司行政管理系统，从数据库脚本、后端接口、前端页面到配套的万字论文，算是一次比较彻底的整理。这篇文章就把整个项目的设计逻辑、落地过程和运行经验拆开来讲，适合正在做毕业设计、准备拿源码二次开发，或者想快速搭一套内部管理后台的同学参考。

1. 传媒公司行政管理系统到底要管什么

1.1 先理清业务边界：一套系统解决哪些行政痛点

我接手这类系统时，第一件事从来不是建表，而是搞清楚行政人员每天都在处理什么。传媒公司的行政部门和其他行业有个明显区别：业务节奏快、项目制明显、临时人员多。今天要协调演播室档期，明天要安排外拍车辆，还要盯着摄像机、灯光、收音设备这种高价值资产的流向。人员入离职频繁，设备借还频繁，会议室冲突是常态，用车申请往往要跟项目时间赛跑。

如果线下用Excel管这些事，最大的问题是信息割裂。设备借给谁了、会议室哪个时段被人占了、车钥匙在谁手里，全靠口头问。行政系统要解决的核心痛点就三句话：资源可查、流程可追、记录可溯。

所以系统第一优先级不是界面好看，而是把"人、事、物、流程"四条线全部数字化。在这个项目里，我把它拆成了四大类：

• 人力基础：部门、岗位、员工档案、账号信息；
• 行政资源：固定资产、办公用品、会议室、车辆；
• 业务流程：请假审批、用车申请、会议室预约、用品申领；
• 信息触达：公告发布、待办提醒、操作日志。

这套边界定下来之后，后面所有功能模块都围绕这四个方向展开，不会跑偏，论文的第三章系统分析也有现成的素材。

1.2 传媒行业的特殊需求：会议室、车辆与设备流转

普通企业的行政系统管会议室和办公用品就够了，但传媒公司还要额外关注三个特殊场景：

会议室的本质是"档期资源"。它不只是一个空房间，而对应着节目录制、项目组讨论、客户提案等具体业务，预约时必须按时间段锁定，否则两个栏目组同时要用演播室就是事故。

车辆调度的核心是"出勤时效"。外拍车、转播车都有任务时间窗口，审批不能拖太久，所以我在设计车辆申请流程时，特意区分了"部门审批"和"车辆管理员派车"两个环节，早一点把时间自由度给到使用者。

设备资产的重点是"借还闭环"。一台摄像机可能值几十万，从哪个项目组借走、什么时候归还、有没有损坏，必须有一条完整的记录。普通企业的固定资产只需要登记流向，传媒公司则更需要把"借用记录"作为核心数据维护起来。

想清楚这些，再去写代码，每一张表的存在意义都很明确，不会出现那种为凑功能而硬凑出来的废表。

2. Spring Boot技术选型：为什么这套栈最适合这类管理系统

2.1 后端框架选型的核心诉求

选 Spring Boot 不是因为它时髦，而是这类管理系统对技术栈的要求，恰好和它匹配到一块了。

首先是交付效率。管理系统有大量重复的增删改查，Spring Boot 配合 MyBatis-Plus，单表 CRUD 几乎不用写 SQL，BaseMapper 直接把方法给你备好了。我说得直白点，这套系统的价值在于业务关系的梳理，而不是每天手写一百行重复的数据库操作。

其次是部署友好。Spring Boot 内置 Tomcat，打包成 jar 之后一条命令就能跑起来，不用单独配 Web 服务器。这对本地调试和服务器部署都很省事，尤其是学生做毕设时，演示环境一台笔记本就搞定，不依赖复杂的生产环境。

第三是排错成本低。Spring Boot 的资料和案例到处都是，遇到问题搜一下基本都有答案。对于个人开发者和学生来说，这比选一个小众框架稳得多。技术选型最怕的不是"不够高级"，而是"出了问题没人能帮你看"。

在具体版本上，我习惯用 Spring Boot 2.7.x 搭配 JDK 8，这个组合兼容性好，依赖也稳定。如果你用 3.x 版本，就要注意 JDK 版本升到 17，MyBatis-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_role_menu 和 sys_user_role 这类关联表连接，形成标准的 RBAC 模型。我建议不要在设计时把权限直接硬编码到用户表里头，不然加角色和调权限的时候会非常痛苦。

申请与审批的关联是这个系统的落点。会议室预约、车辆申请、请假记录、用品申领，这些表本质上是同一类模式：业务表加上一个状态字段，再关联一条流程记录。用统一的处理逻辑去处理，代码量会少很多，后面我单独说状态机。

3.2 状态机设计：审批流如何落库

审批类功能是整个行政系统里最容易写乱的模块。很多初次做这种项目的人会把审批状态放在业务表里，然后用一个 if-else 把所有逻辑串起来，后面加审批层级就崩溃。

我的做法是给每张业务表设计一个 status 字段，取值统一规范一下：

如果系统是单级审批，表里加一个 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 环境准备清单

拿到项目的源码加数据库脚本之后，环境对不齐是第一个坑。我列一下这套环境的版本建议，照着配基本不会出问题：

我建议用 IDEA 打开后端目录，用 VS Code 或 IDEA 打开前端目录，两边分开跑，不然两个项目堆在同一个窗口里看日志很混乱。数据库工具可以用 Navicat 或 DataGrip，导入脚本的时候直接执行整个 .sql 文件。

5.2 启动步骤与关键配置

后端启动前最重要的一步是修改数据库连接配置。打开 application.yml，把 MySQL 的地址、账号、密码改成你自己的：

spring: datasource: url: jdbc:mysql://localhost:3306/admin_system?serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8 username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

这里我特别强调一下 serverTimezone=Asia/Shanghai，很多人在 MySQL 8 下启动报错，都是因为没有配置时区。然后按顺序来：

1. 在数据库里新建一个空白库，名字和配置里的库名保持一致；
2. 用 Navicat 或命令行导入项目自带的 .sql 脚本；
3. 先启动后端 Spring Boot 主类，看到 Tomcat started 的日志说明后端起来了；
4. 再进前端目录，执行 npm install 安装依赖，然后 npm run dev 启动；
5. 浏览器访问前端地址，用管理员账号登录。

如果脚本里建过库，执行时要注意选择正确的目标库。命令行导入的方式是mysql -u root -p admin_system < admin_system.sql，前提是库已经建好。

5.3 常见报错排查表

我把实际运行中高频出现的报错和处理方式汇总成一个表，照着排查比较快：

调试时我习惯先把后端接口调通，用浏览器直接访问一个接口地址，确认返回 JSON 后再调前端页面。这样可以减少前后端同时出问题的排查范围，效率最高。

6. 拿到源码之后：如何快速读懂并做二次开发

6.1 代码目录结构：先看哪里、后看哪里

如果你拿到的是一份完整的项目源码，几千个文件摆在那，别急着到处点。我自己的阅读顺序是：先看数据库脚本，再看后端代码结构，最后看前端页面。

后端最核心的目录就几个：

• controller 层：看有哪些接口，理解每个功能模块对外暴露了什么；
• service 层：看业务逻辑，尤其审批状态流转都在这层；
• mapper 层：看数据库操作，如果用了 MyBatis-Plus，大部分只是继承 BaseMapper；
• entity 层：看实体对应哪些数据库表；
• 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 图再写测试用例，因为测试本质上也是对着流程走一遍。系统跑通之后，我最大的体会是：这类管理系统的真正难点不在技术上，而在状态流转的完整性和数据边界的合理性上。把审批状态机设计清楚，把会议室冲突判断做严谨，把操作日志铺到位，剩下的功能模块都会变成流水线式的体力活。如果你准备开题或者正在改代码，建议先花一个晚上把表结构和状态枚举图画出来，再碰具体的业务代码，后面至少能少熬三个通宵。