企业官网建设流程全解析

每到毕业设计选题季，总有人来找我聊同一个话题：工会管理系统能不能做、好不好做。答案是好做，但大多数人交上来的版本只有两种结局——要么被导师评价为"换了个名字的员工信息管理系统"，要么演示到一半自己都心虚，因为里面没有任何一条真实的业务规则。

这篇帖子就把这类题目按"认真做一遍"的思路拆开讲：从需求分析、数据库设计，到SpringBoot加Spring MVC结构下的核心代码落地，再到答辩环节老师一定会追问的几个点。内容基于我实际做过这类项目的经验，不是课程设计模板里抄来的壳，适合正在做这个题目、或者代码已经写完了却说不出设计思路的同学。

先把丑话说在前面：这个题能不能做出亮点，不在于你堆了多少新技术，而在于你有没有把工会业务本身的逻辑捋顺。会费怎么算、会员状态怎么流转、活动报名怎么防重复、审批流程怎么控制，这些才是真正拉开差距的地方。

1. 拆解题目：这个系统到底要管什么

1.1 先画业务流程，再画功能菜单

很多人拿到题目就打开数据库设计工具，先建一张员工表，然后开始复制粘贴"增删改查"。这就是项目做得水的最根本原因——顺序反了。

正确的做法是先想清楚业务闭环。工会管理系统核心业务对象其实很明确：会员、会费、活动、慰问、公告。会员是基础档案，会费和活动是两条主线，慰问和补助是带审批流的扩展能力。围绕这几条线，至少要能跑通下面这些闭环：

• 会员入会：登记基本信息，确认入会时间，初始化会员状态，同时生成首期会费记录。
• 会员状态变更：转出、离职、退休，每次变更都必须留下历史流水。
• 会费缴纳闭环：系统按规则生成应缴记录，干事确认到账，更新缴费状态。
• 活动闭环：发布活动、员工报名、活动签到、费用统计、活动归档。
• 补助慰问申请：会员提交申请，干事初审，负责人审批，审批结果回写申请单。

把这些流程列出来，功能菜单自然就长出来了。注意，这里每一步都不是简单的"表操作"。"活动报名"背后要考虑名额限制、报名截止时间、重复报名校验这类真实约束。这些约束，就是答辩时你能展开讲的内容。

1.2 会费计算规则：题目里的隐藏考点

会费计算是这个系统最能体现业务功底的地方。不同单位的规则不一样，常见的有三种：

代码里不要把这些规则写死在业务逻辑中，建议单独做一张计费规则配置表，字段包括：规则名称、计算方式（固定/比例/分档）、金额或比例值、生效时间。生成会费记录时统一走一个"会费计算器"，根据规则配置算出每个人的应缴金额。这样改规则只是改配置，答辩时也能说清楚"规则与业务分离"的设计思路。

1.3 角色权限：三种角色足够，但边界要说清楚

我建议角色就设计三种：系统管理员、工会干事、普通会员。管理员管用户账号和基础配置；干事管会员档案、会费、活动的日常维护；会员只能看自己的会费记录、报名活动、提交补助申请。

比功能权限更值得展开的是数据权限。干事可以看到全量会员列表，但只能维护自己分管的部门或分工会；会员查询会费记录时，后端必须强制加当前登录人ID的过滤条件。这种行级数据权限是大多数毕设模板里缺失的，也是导师眼前一亮的地方。

2. 技术选型与工程结构：把SpringBoot加MVC用扎实

2.1 这套组合为什么是当前最佳范围

题目要求SpringBoot基于MVC，这本身就是目前Java后端的主流搭配。SpringBoot解决了过去Spring配置繁琐的问题，内嵌Tomcat可以直接打包运行；Spring MVC的Controller-Service-DAO分层把请求处理、业务逻辑、数据访问拆开，配合注解驱动开发，代码结构清楚。

这里的MVC既可以是经典的Spring MVC分层，也可以做成前后端分离：前端用Vue或者Thymeleaf都行，后端只提供JSON接口。对于毕设演示，我更推荐后端接口加RESTful风格，答辩时光是接口设计、状态码、统一返回结构就能单独拿出来讲好几分钟。

2.2 工程目录怎么分

我常用的包结构是这样的：

src/main/java/com/xxx/union ├── controller // 接口层：只做参数接收和结果封装 ├── service // 业务层：核心业务规则都在这层实现 ├── mapper // 数据访问层：MyBatis-Plus或Spring Data JPA ├── entity // 数据库实体映射 ├── dto // 入参对象，接收前端请求参数 ├── vo // 出参对象，返回给前端展示的数据模型 ├── config // 配置类：跨域、拦截器、MyBatis配置 ├── common // 公共模块：统一返回结构、异常、常量 └── utils // 工具类：日期、Excel、校验

有一个很容易被忽略的点：不要直接用Entity接收前端参数，也不要直接返回Entity给前端。数据库表字段改动会直接影响接口结构，而且像手机号、身份证这类敏感字段容易发生泄露。用DTO和VO做隔离，是代码质量层面的加分项。

2.3 统一返回结构和全局异常：必须有的门面

几乎所有接口都要返回固定结构，比如：

public class Result<T> { private int code; private String message; private T data; public static <T> Result<T> ok(T data) { return new Result<>(200, "success", data); } public static <T> Result<T> fail(int code, String message) { return new Result<>(code, message, null); } }

再配合@RestControllerAdvice做全局异常处理，业务异常、参数校验异常、未知异常分别返回不同的错误码。写完这两段，Controller里就不用到处写try-catch，每行代码都在表达业务，而不是在处理杂事。答辩老师问"你的异常体系怎么设计的"，这段配合就能回答得很完整。

3. 数据库设计：真正决定项目上限的部分

3.1 核心表结构和关系

表不需要多，但每一张都要站得住。我建了这么几张核心表：

• member：会员主表。字段包括id、工号、姓名、性别、手机号、部门/分工会、入职日期、会员状态、入会日期。
• member_transfer_log：会员状态变更流水表。字段包括member_id、变更前状态、变更后状态、变更原因、操作人、变更时间。
• dues_record：会费记录表。字段包括member_id、归属月份、应缴金额、实缴金额、缴费状态、缴费时间、收款方式。
• activity：活动表。字段包括标题、内容、开始时间、结束时间、报名截止时间、名额限制、活动地点、负责人。
• activity_registration：活动报名表。字段包括activity_id、member_id、报名时间、签到状态，并加唯一约束(activity_id, member_id)。
• approval_form：审批单通用表。字段包括form_type、applicant_id、业务单号、审批状态、当前节点、提交时间、完成时间。
• union_notice：公告表。字段包括标题、内容、发布时间、是否置顶、发布人。

表不多，但关系是完整的。特别注意有流水表就意味着系统里不存在物理删除"会员"的操作，只有状态变更。这种设计符合真实业务场景，也能在答辩时讲清楚"为什么不做删除功能"。

3.2 状态字段：用数字字典值，别存中文

会员状态我用tinyint存储，Java侧用枚举维护：

public enum MemberStatus { NORMAL(1, "在职正常"), TRANSFERRING(2, "待转会"), RETIRED(3, "退休保留"), RESIGNED(4, "已退会"); }

存数字而不是中文，好处有三个：存储体积小；状态显示文案可以随时改；业务判断不受文案影响。显示转换交给VO层，这也是"存储与展示分离"的体现。

会费记录同样有状态机：待缴费、已缴费、已减免、已退费。每一次状态变化都要记录时间或操作来源，这些字段是后面做统计报表的依据。

3.3 统计数据用预聚合，别每次都实时算

毕设经常要做"年度收缴率""活动参与率"这类统计。如果都从业务表里实时COUNT和GROUP BY，SQL写得复杂不说，数据量上来之后还会拖慢主流程。

我的做法是建一张统计汇总表，字段包括统计类型、统计维度、归属期间、指标值、生成时间。月结任务跑一次，把各类统计结果写进去，报表页面直接查这张表。答辩时讲"为了性能做预聚合"的设计，比只说一句"用了缓存"要扎实得多。

4. 核心模块落地：写实这几个功能就够撑门面

4.1 会员Excel导入：校验比读取更重要

会员档案经常要从线下Excel批量导入。用EasyExcel读取数据时，工作量不在读取，而在逐行校验。我的做法是：每一行都校验工号唯一性、手机号格式、必填字段；校验失败不中断，把错误行和错误原因收集起来，导入完成后返回一个失败清单文件。

这样一次导入能反馈全部问题，而不是改一行导一次。几百上千条数据几分钟搞定。注意Excel里的日期字段要显式指定格式，我踩过默认读取成数字序列号的坑，这个放到最后一部分细讲。

4.2 会费批量生成：必须考虑幂等

会费记录生成的标准做法是跑批：根据会员列表和计费规则，计算出每位会员当期应缴记录，然后批量插入。

@Transactional(rollbackFor = Exception.class) public void generateMonthlyDues(String period) { List<Member> members = memberMapper.selectByStatus(MemberStatus.NORMAL); List<DuesRecord> records = new ArrayList<>(); for (Member m : members) { // 同一周期已经生成过的会员直接跳过，防止重复跑批 if (duesMapper.existsByMemberAndPeriod(m.getId(), period)) { continue; } DuesRecord record = buildDuesRecord(m, period); records.add(record); } saveBatch(records); }

这里最关键的是幂等控制。跑批任务可能因为网络、异常被重复触发，如果没有"同一会员同一周期只能一条记录"的保证，数据很快就脏了。数据库唯一索引加代码判断，双重保障都要有。

4.3 活动报名：数据库唯一约束比代码判断更可靠

活动模块最容易演示出效果，也最容易埋雷。报名时要校验：是否在报名期内、名额是否满、是否重复报名。代码里可以写判断，但数据库层必须加唯一索引(activity_id, member_id)。原因是并发情况下，两个请求可能同时通过代码判断，最终要靠唯一索引兜底。

签到同理，一个会员对一场活动只能签到一次。签到状态反过来可以算活动参与率：已报名人数、实际签到人数、签到率，这些是活动总结的基础数据。

4.4 审批流程：用状态机替代一堆if判断

慰问和补助申请需要走审批。很多同学在Controller里写if(状态 == 1)可以做A，if(状态 == 2)可以做B，状态一多代码就乱。

我习惯把流转规则集中到状态机里：

public enum ApprovalStatus { DRAFT(0, "草稿"), PENDING(1, "待审批"), APPROVED(2, "已通过"), REJECTED(3, "已驳回"), REVOKED(4, "已撤回"); public static ApprovalStatus next(ApprovalStatus current, String action) { // 流转规则集中维护在这里 // 例如 PENDING + "approve" -> APPROVED // PENDING + "reject" -> REJECTED } }

每次审批动作都只传当前状态和目标动作，由状态机决定能不能流转。以后要加审批层级，改状态机就够了，不用翻一堆Controller。单是"为什么不用if而用状态机"这个问题，就够答辩时聊上两分钟。

5. 登录鉴权与接口安全：别让答辩卡在这一关

5.1 登录方式怎么选

这个项目涉及三类角色，登录鉴权是逃不掉的。方案上有两条路：一是用Spring Security加Spring Security集成JWT，二是自己写拦截器加JWT。

我的建议是，如果时间宽裕且想毕业设计里体现"标准方案"，用Spring Security；如果代码已经写了一半，自己实现拦截器也完全够用。核心点在于：登录成功后签发Token，前端每次请求在请求头携带，后端拦截器校验Token并把当前用户信息放进上下文。这个链路讲清楚，比单纯说"用了框架"更有说服力。

5.2 权限控制的两个层次

功能权限用注解加拦截器实现：

@Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface RequireRole { String value(); // "ADMIN", "OFFICER", "MEMBER" }

在Controller方法上标注需要的角色，拦截器在进入方法前检查。比在方法体里写if判断当前角色干净得多。

数据权限在Service层做。比如会员查询会费记录时，如果不是管理员或干事，直接把当前登录人ID拼到查询条件里。这个强制过滤规则不能靠前端隐藏按钮实现，必须后端兜底。

5.3 接口安全必答点

有几个安全点建议全部覆盖，答辩必问：

• 密码不能明文存储，使用BCrypt单向加密。
• 入参用@Valid注解校验，避免脏数据进入Service。
• 简单XSS过滤，对前端传过来的字符串去掉危险标签。
• 表单重复提交，关键接口做一次幂等控制，方式可以是Token防重或者唯一索引。

别小看这些，有一个能展开讲半个小时。比如"前端已经校验了格式，为什么后端还要校验"，答案就是信任边界问题——前端是开放的，后端才是真正的安全边界。

6. 实测中踩过的坑与答辩准备思路

6.1 三个印象深刻的坑

先说EasyExcel日期问题。用Excel导入会员信息时，日期列不指定格式，读出来会是一串类似45000的数字序列号，插入数据库直接变成1970年的日期。解决方式是读取时显式声明日期格式，比如"yyyy-MM-dd"的字符串格式，入库前再做转换。

第二个坑是时区问题。前端传一个起始日期和结束日期，后端直接当字符串拼接SQL查询，结果因为MySQL和Java应用服务器时区不一致，边界那天凌晨的数据查不进去。后来统一通过配置连接参数指定时区，并且所有日期在接口层用统一格式规范处理，这类问题就消失了。

第三个坑是事务自调用失效。写会费跑批时，我在一个类内部用this调用另一个带@Transactional的方法，发现事务根本没生效。原因是被Spring代理的类，自调用不走代理，注解失效。把需要事务的逻辑拆分到另一个Service，或者使用代理对象调用，才算真正解决。这个问题很经典，答辩大概率会问。

6.2 让系统"看起来不水"的几个加分项

如果时间和精力允许，强烈建议补这三个功能：

一是操作审计日志。谁在什么时间改了什么，旧的字段值是什么，新的字段值是什么，记录到一张日志表。这属于"改动留痕"，任何管理系统都绕不开。

二是PDF导出。会费对账单、活动通知单做成PDF模板，在线生成后下载。演示的时候现场导出一张对账单，效果比任何口头描述都直观。

三是统计图表展示。用ECharts把年度收缴率、月度活动数量、各部门参与情况做成图表放首页。这不只是好看，还能和前面设计的预聚合统计表形成呼应。

6.3 答辩高频问题清单

下面这些问题我几乎每次都会被问，提前准备好答案：

最后说一句自己的体会。这类题目年年有人做，能拿到理想成绩的，往往不是功能数量最多的那个，而是把一条主线做深了的那个。我一开始也走过弯路，一口气做了十几个菜单，结果每个只能讲出增删改查。后来狠心砍掉一半功能，重新盯住"会费加活动"这条闭环，从规则配置到状态流转再到统计报表全部打通，反而内容多了不少。如果你手头的版本也是那种什么都有一点、什么都说不深的，建议先做减法，把剩下的故事讲完整，效果会好很多。