每到毕业设计季，“管理系统”这四个字就是绝对的热门关键词。而在所有管理类题目里，**“农村基层治理信息系统”**又属于出镜率极高的一类，标题往往还会带上一串限定词：Java、SpringBoot、Web版、乡村政务治理管理平台。我收到过不少来做这个题目的同学的私信，问得最多的无非是“这个系统到底该有哪些功能”“技术栈怎么选”“数据库怎么设计”，以及最要命的“一个月做得完吗”。
先把这类题目拆开看：它本质上是一个面向村级政务场景的Web管理平台，把村务公开、村民办事、人口资产管理、意见反馈这些线下日常工作搬到网页上，让村干部和村民能在同一套系统里完成信息发布、申请审批和数据查看。现实中的使用对象就是村两委的工作人员和普通村民，核心逻辑是给传统政务流程做信息化改造，这确实是一个有现实意义的选题方向。
如果你正在做或者准备做这个题目，这篇内容应该能帮上忙。我会按一个完整毕设项目应该怎么推进来讲：先拆业务需求，再定技术方案，然后落到数据库设计、核心功能实现、常见坑点和答辩准备，整套思路都基于常规Spring Boot项目开发实践展开，能直接照着落地。
1. 项目整体设计与功能模块拆解
1.1 系统到底在解决什么问题
农村基层治理的真实工作场景其实相当庞杂，而信息化系统的切入点无非三件核心的事：信息上墙、流程上线、数据入档。
所谓信息上墙，就是村务公开。线下靠村口公告栏贴纸的方式覆盖面有限，换成系统里的“村务公开”栏目，村民随时随地能看公示内容，也方便事后查询和留痕。流程上线则是指村民办事这件事，比如开具证明、申请低保、宅基地审批这类流程，线下要跑好几个地方、反复问进度，线上则可以通过“提交申请—状态跟踪—结果通知”的方式跑完闭环。数据入档就更好理解了——人口信息、房屋信息、土地信息、党员信息这些分散的表格，统一落到数据库里做结构化存储，后续查询、统计、导入导出都比翻Excel方便得多。
1.2 用户角色与权限边界怎么定
做管理系统，第一步永远是定角色，角色没想清楚，后端的接口权限和数据库设计都会乱。我建议把用户分为四类：
- 村民：浏览首页公告，在个人中心提交办事申请、查看办理进度、发表意见建议。
- 村干部/网格员：发布村务信息，处理村民提交的办事申请，维护本村的人口和资产数据，回复村民意见。
- 乡镇管理员：查看下辖各村的汇总数据，对超时未处理的流程进行督办，维护系统基础数据字典。
- 系统管理员：管理用户账号、分配角色、查看操作日志、配置系统参数。
一个细节提醒：毕设项目不要把权限模型搞得太复杂。细化到每个按钮级别的细粒度权限控制，在企业级系统里往往是必须的，但放在毕业设计的时间节奏里性价比不高。做到“菜单可见性 + 接口访问控制”这个层级就够了，用拦截器校验角色身份，简单直接，答辩时也说得清楚。
1.3 核心功能模块清单
| 模块名称 | 核心功能 | 主要使用角色 |
|---|---|---|
| 登录认证 | 账号密码登录、JWT签发与校验、退出登录 | 所有用户 |
| 首页工作台 | 通知公告轮播、待办数量提醒、最新动态 | 所有用户 |
| 村务公开 | 公告发布、编辑、撤回、附件上传、置顶排序 | 村干部 |
| 村民办事 | 办事指南查看、在线申请提交、进度查询、办理结果反馈 | 村民、村干部 |
| 人口管理 | 户籍人口信息维护、按条件查询、按户展示、导入导出 | 村干部、乡镇管理员 |
| 资产管理 | 房屋、土地、集体资产登记与查询，资产变更记录 | 村干部、乡镇管理员 |
| 党建管理 | 党员信息维护、组织生活记录、学习资料发布 | 村干部 |
| 意见箱 | 村民提交意见建议、村干部回复、匿名/实名切换 | 村民、村干部 |
| 数据统计 | 各模块数据按时间、类型汇总，可视化图表展示 | 乡镇管理员、村干部 |
| 系统管理 | 用户管理、角色分配、日志查看、参数配置 | 系统管理员 |
1.4 业务闭环的串联逻辑
这些模块不是孤立的，它们之间有一条主线：村民通过“办事入口”提交申请 → 村干部在“待办列表”看到并进行处理 → 村民随时查看进度 → 完成后村务公开模块同步展示结果 → 数据统计模块实时汇总办理量。这条链路实际上就是整个系统的核心价值。很多人做毕设容易把系统做成“多个增删改查页面的堆叠”，本质上就是没有把业务串起来。建议在画原型或写文档时，先把这条主线标注出来，再用它来验证模块设计是否合理。
2. 技术方案选型与核心架构解析
2.1 为什么偏偏是Java+SpringBoot
毕设题目里指定Java + SpringBoot是很有道理的，不是随便拍的。Spring Boot在国内开发者群体里的生态太成熟了，遇到问题搜索答案几乎是一搜一个准；同时它内置Tomcat，打包成单jar就能跑，部署门槛远低于传统的Servlet + Tomcat手动配置方案；再加上它基于Maven管理依赖，开发者只需要关注业务代码，自动配置帮我们省掉大把的时间。
对毕业生来说还有一层现实考量：Java岗位在市场上的需求量常年稳定，管理类题目选择Java技术栈，在答辩、简历、后续面试里聊起来都有内容可讲。无论是Spring Boot的核心机制、MyBatis-Plus使用，还是JWT认证原理，都是面试里能直接扯出话来的技术点。
2.2 前端渲染方案选哪种
前端方案是很多同学纠结的地方，我直接说结论：时间紧就选模板引擎，想展示更多能力就选前后端分离。
方案A：Thymeleaf + Bootstrap早期Java Web项目最常见的方式。后端用Controller返回视图，Thymeleaf模板里写HTML并混入服务端渲染的数据，Bootstrap负责样式。优点是没有任何跨域困扰，服务端和页面在一个工程里，部署就是一个jar；缺点是前端体验相对传统，页面跳转比较多，动态交互需要配合jQuery或者原生JS去写。
方案B：Vue3 + Element Plus + RESTful API前后端分离，前端工程通过axios调后端接口。界面美观度和交互流畅度远高于模板方式，也是目前企业开发的主流形态，在答辩和简历里的含金量更高。但代价是要多维护一套前端工程，Node环境、构建工具、跨域处理都需要额外投入时间。
我在实际项目里更推荐多数同学选方案B的简化版——用Vue3 + Element Plus，接口遵循统一RESTful风格，前后端分开部署或后端托管前端静态文件都可以。如果你之前几乎没有前端基础，那就老老实实选方案A，把精力留给后端业务和数据库设计，一样能做出完整作品。
2.3 核心依赖和版本怎么选
后端基于Spring Boot，建议选择稳定的大版本。如果你用的是JDK 8，那就对应Spring Boot 2.7.x；如果JDK 17，可以上Spring Boot 3.2.x。从兼容性角度讲，大多数公开教程和插件对2.7的支持更广泛，选题里没有特别要求就用2.7.x，踩坑概率低。
一个典型的pom依赖清单大概长这样：
<dependencies> <!-- Web开发起步依赖 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!-- MyBatis-Plus，操作数据库的利器 --> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <!-- MySQL驱动 --> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <!-- Lombok，减少实体类样板代码 --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <!-- JWT工具库 --> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9.1</version> </dependency> <!-- 常用工具类库，处理字符串、日期、文件很节省时间 --> <dependency> <groupId>cn.hutool</groupId> <artifactId>hutool-all</artifactId> <version>5.8.20</version> </dependency> </dependencies>特别提醒一点：jjwt 0.9.1这个版本在JDK8环境下工作正常，如果用了JDK9以上，可能需要额外引入javax.xml.bind依赖，不然会报ClassNotFoundException。这类版本兼容细节，等你真正踩到的时候会感谢这句话的。
2.4 包结构设计
包结构是代码可维护性的基础。推荐按“模块-技术层”混合拆分的方式：
com.village.govern ├── controller // 接口层，接收请求，返回Result统一结构 ├── service // 业务层，处理核心逻辑 │ └── impl // Service实现类 ├── mapper // MyBatis-Plus的Mapper接口 ├── entity // 数据库实体 ├── dto // 前端传参对象、返回对象 ├── config // 配置类，如拦截器、静态资源映射、跨域配置 ├── common // 通用类，如Result返回体、业务异常、常量类 ├── util // 工具类，如JWT工具、日期工具 └── VillageGovernApplication.java // 启动类为什么Controller要很薄？因为业务逻辑不应该堆在接口层。Controller只做参数接收和结果返回，业务计算放到Service层，数据库操作全部封装在Mapper层，这样架构目的只有一个——出问题的时候能找到地方改，而不是整个文件全都得翻一遍。这是分层架构最朴素的理由。
3. 数据库设计与核心功能实操实现
3.1 核心表结构的设计思路
数据库设计直接决定后期开发效率。这套系统的核心表大致包括：用户表、角色表、村务公告表、办事申请单表、办事类型表、人口信息表、房屋土地资产表、意见反馈表、操作日志表。空间有限，重点说几个绕不开的表。
用户表（sys_user）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键，自增 |
| username | varchar(50) | 登录名，唯一 |
| password | varchar(100) | 加密后的密码（BCrypt） |
| real_name | varchar(50) | 真实姓名 |
| phone | varchar(20) | 手机号 |
| role_id | int | 角色外键 |
| village_id | int | 所属村ID |
| status | tinyint | 账号状态 0正常/1禁用 |
村务公告表（biz_notice）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| title | varchar(100) | 公告标题 |
| content | text | 公告正文 |
| attach_path | varchar(255) | 附件存储路径 |
| publish_user | varchar(50) | 发布人姓名 |
| village_id | int | 发布所属村 |
| is_top | tinyint | 是否置顶 0/1 |
| create_time | datetime | 发布时间 |
办事申请单表（biz_apply）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| apply_no | varchar(50) | 申请编号，可用于查询进度 |
| user_id | int | 申请人ID |
| affair_type | int | 办事类型ID |
| content | text | 申请事由 |
| status | int | 0待审核/1审核通过/2已完成/3已退回 |
| handle_user | varchar(50) | 处理人姓名 |
| handle_remark | varchar(255) | 处理意见 |
| create_time | datetime | 提交时间 |
| update_time | datetime | 办理完成时间 |
意见建议表（biz_suggestion）
| 字段名 | 类型 | 说明 |
|---|---|---|
| id | bigint | 主键 |
| user_id | int | 提意见的村民ID |
| is_anonymous | tinyint | 是否匿名 0/1 |
| content | text | 意见内容 |
| reply_content | varchar(500) | 村委回复内容 |
| reply_time | datetime | 回复时间 |
| create_time | datetime | 提交时间 |
这些表背后的逻辑就是一个词：事件留痕。每条数据都记录创建时间和处理人，后面统计、追责、复查都有据可查。答辩时讲到这个设计考虑，是加分项。
3.2 登录认证与权限拦截的实现
登录这块建议直接用JWT方案。和传统Session相比，JWT在前后端分离的场景里天然友好，服务端不需要保存会话状态，用户登录后拿到一个token，后续请求在Header里带上即可。核心步骤如下：
用户提交用户名密码 → 校验通过后生成JWT返回前端 → 前端后续请求携带token → 后端拦截器解析token并校验角色。
JWT工具类的关键代码大致是这样：
@Component public class JwtUtil { // 密钥，实际项目中应该放在配置文件中并妥善保管 private String secret = "your-256-bit-secret"; private long expire = 7 * 24 * 3600; // 过期时间7天，单位秒 public String createToken(Long userId, String roleCode) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("role", roleCode) .setExpiration(new Date(System.currentTimeMillis() + expire * 1000)) .signWith(SignatureAlgorithm.HS256, secret) .compact(); } public Claims parseToken(String token) { return Jwts.parser().setSigningKey(secret).parseClaimsJws(token).getBody(); } public boolean validateToken(String token) { try { parseToken(token); return true; } catch (Exception e) { return false; } } }拦截器的核心逻辑则是拿到请求头里的token → 校验 → 把当前用户信息塞进ThreadLocal或Request域供后续使用。我习惯用ThreadLocal来保存登录用户ID，这样Service层可以随时通过上下文获取当前操作人，写业务日志的时候非常方便。
实现拦截器时要注意排除放行路径，比如登录接口、首页公告列表、静态资源这些不需要登录也能访问的地址，千万别一刀切把所有接口都拦住。
3.3 村务公开模块与附件上传
村务公开模块本身是标准的增删改查，但加上了附件上传之后就多了几个细节。发布公告时，村干部可能会附带PDF或图片，这时后端需要处理文件接收、校验、存储和访问。
文件上传部分用Spring Boot的MultipartFile接收，简单直接：
public String uploadFile(MultipartFile file) { // 动态生成存储目录，按日期分目录避免单目录文件过多 String uploadDir = "C:/village-files/" + LocalDate.now(); File dir = new File(uploadDir); if (!dir.exists()) dir.mkdirs(); // 生成唯一文件名，避免中文乱码和同名覆盖问题 String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String fileName = UUID.randomUUID().toString().replace("-", "") + ext; // 执行保存 file.transferTo(new File(dir, fileName)); // 返回数据库里要存的相对路径 return "/files/" + LocalDate.now() + "/" + fileName; }文件保存之后，要解决访问问题。Spring Boot默认只映射static目录下的静态资源，上传到外部目录的文件需要手动加映射，在配置类里这样处理：
public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/files/**") .addResourceHandler("file:C:/village-files/"); }上传这块很多人踩的坑是：默认文件大小限制1MB，传个两三兆的扫描件就报错。要记得在配置文件里调大限制。另外要确认外部存储目录的真实路径，Windows和Linux写路径的差异巨大，建议写绝对路径。
3.4 办事申请流程的状态流转
办事申请模块是整个系统的业务枢纽，也是最容易讲出亮点的部分。关键在于状态设计，我用一个整数状态字段来表示流程进度，避免用字符串标识，效率更高也更好做统计查询：
| 状态值 | 含义 | 下一步动作 |
|---|---|---|
| 0 | 待审核 | 村干部接单，改为1或3 |
| 1 | 审核通过/处理中 | 办理完成后改为2 |
| 2 | 已完成 | 流程结束，生成办结记录 |
| 3 | 已退回 | 退回原因写入handleRemark，结束或允许重新提交 |
Service层的核心代码逻辑集中在状态更新方法上：
@Transactional public void handleApply(Long applyId, Integer toStatus, String handleRemark, Long operatorId) { // 1. 查询申请单，判断当前状态是否支持这个变更 BizApply apply = applyMapper.selectById(applyId); if (apply == null) { throw new BusinessException("申请记录不存在"); } if (!canChangeStatus(apply.getStatus(), toStatus)) { throw new BusinessException("当前状态不允许该操作"); } // 2. 更新状态和处理信息 apply.setStatus(toStatus); apply.setHandleUser(userService.getUserById(operatorId).getRealName()); apply.setHandleRemark(handleRemark); apply.setUpdateTime(LocalDateTime.now()); applyMapper.updateById(apply); // 3. 写入操作日志 logService.record("办事申请", applyId, "状态变更为" + toStatus); }加了@Transactional事务注解很重要，一个人口登记、资产变更、意见回复等场景，一旦中途报错，数据库状态就不完整了。这一点在答辩时也会被问到。
流程到这里，村民端就能通过申请编号或者登录后的个人中心查看进度了。前端进度展示可以做成时间轴的样式，把每一步处理时间和处理意见列出来，体验和专业度都会大幅提升。
3.5 数据统计与可视化
数据大屏或者统计报表是这类系统展示时最能抓住眼球的部分。实现不算难，但要注意统计SQL的设计。比如要统计每个月的办事申请量，核心SQL逻辑直接画出来：
SELECT DATE_FORMAT(create_time, '%Y-%m') as month, COUNT(*) as total FROM biz_apply WHERE create_time >= #{startTime} GROUP BY DATE_FORMAT(create_time, '%Y-%m') ORDER BY month有了数据之后，前端用ECharts画折线图或柱状图，几分钟就能出一张看起来很专业的界面。我的建议是统计模块至少包含四个维度：办事申请趋势、公告发布量对比、各村待办数量排名、意见反馈处理率。这些指标既体现系统运营情况的全局画像，又不需要做太重的前端渲染。
如果怕统计查询扛不住压力，可以在中间加一层缓存，Spring Boot里最简单的做法就是给统计Service方法加@Cacheable注解，或者直接用Redis缓存统计结果，设置5分钟的过期时间。毕业设计的数据量级根本不会打爆数据库，但加了这层设计，答辩时无论老师问“大数据量下的性能优化”还是“怎么提升接口响应速度”，你都有话可接。
4. 开发中常见问题与排查技巧实录
这个部分我直接贴自己实际遇到的高频问题，按出现概率从高到低排，排查思路也是可以直接照做的。
4.1 环境搭建期的三个高频报错
报错一：启动类相关依赖冲突。最常见的是Spring Boot 2.7版本里引入了3.x的较新依赖，导致自动配置失败，控制台刷一片红色，提示描述可能是“Invalid parameter name”或“Error creating bean”。解决思路很简单：锁定项目使用唯一一套Spring Boot版本管理，第三方依赖不要随意加高版本，尽量以Spring Boot官方BOM为准。
报错二：端口被占用。启动时看到“Port 8080 was already in use”，说明你之前的应用没关干净，或在H2/Tomcat之外还有别的进程占着端口。解决方式就是找出来杀掉，Windows下用netstat -ano | findstr 8080查PID，再taskkill /F /PID 数字；Linux/mac下用lsof -i:8080。
报错三：Lombok生成的getter/setter找不到。IDEA里一旦提示“找不到符号getXxx()”，第一反应检查Lombok插件是否装了、是否开启注解处理。Spring Boot项目里做实体类，省掉getter/setter确实爽，但前提是IDE插件和依赖都在。
4.2 数据库连接与中文乱码问题
数据库这块是重灾区。连MySQL时报“Public Key Retrieval is not allowed”解决办法是在JDBC连接串里加上allowPublicKeyRetrieval=true&useSSL=false。时区报错则是连接串里没指定服务器时区，加上serverTimezone=Asia/Shanghai。中文乱码也不在少数，Maven工程的application.yml里，数据源URL一定要显式设置characterEncoding=utf8，创建表的时候也要保证表本身是utf8mb4字符集，否则数据库表没建对，后端代码怎么改都白搭。
最终的稳妥配置长这样：
spring: datasource: url: jdbc:mysql://localhost:3306/village_db?serverTimezone=Asia/Shanghai&characterEncoding=utf8&useSSL=false&allowPublicKeyRetrieval=true username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver4.3 MyBatis-Plus使用的三个注意点
MyBatis-Plus虽然封装了大量通用方法，但没有魔法，该懂的原理还是得懂。
- 表名和实体类名不一致。默认情况下，实体类
BizApply对应表biz_apply，这是没错的。但如果是User对应sys_user这种，就必须加@TableName("sys_user")注解，不然运行期告诉你表不存在，你得反应半分钟才意识到是命名问题。 - 驼峰映射开关。实体类属性
createTime要映射到数据库列create_time，需要在application.yml里开启map-underscore-to-camel-case: true。Spring Boot + MyBatis-Plus大多数情况下默认开着，但写自定义SQL时还是要留意，避免结果集copy不过去。 - 分页插件要主动配置。用
selectPage方法，如果返回结果一直是全量数据，大概率是漏配了分页插件。需要在配置类里注册MybatisPlusInterceptor并添加PaginationInnerInterceptor。
4.4 前后端联调时的两个典型问题
跨域问题：前后端分离部署时，前端页面在localhost:5173，后端接口在localhost:8080，浏览器会直接拦截跨域请求。解决方式最快捷的是后端写一个配置类实现WebMvcConfigurer，在addCorsMappings里允许对应源的跨域访问；或者前端配置代理转发。注意跨域配置别写成allowedOrigins("*")就万事大吉，生产环境里这是安全隐患，尽量精确到前端项目的地址。
统一响应结构：我强烈建议所有接口统一返回Result<T>，里面至少包含code、msg、data三个字段。这样前端就能统一拦截处理错误提示，不用每个接口单独判断逻辑。而排查问题的时候，看到code非200也能迅速定位是业务异常、参数校验失败还是系统错误。
@Data public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> success(T data) { Result<T> r = new Result<>(); r.setCode(200); r.setMsg("操作成功"); r.setData(data); return r; } public static <T> Result<T> error(Integer code, String msg) { Result<T> r = new Result<>(); r.setCode(code); r.setMsg(msg); return r; } }统一响应结构不是一个可选项，在我眼里属于必做项。因为用拦截器做了异常兜底之后，整个系统的前后端沟通语言就统一了，开发效率能提升一个档次。
4.5 打包部署的几个小坑
本地跑得好好的，打包成jar就出问题，这类事太常见了。列出几个我印象深刻的：
- 资源文件没打包进去：
src/main/resources下的XML文件和模板文件在打包后如果找不到，检查pom.xml里是否过滤掉了XML文件后缀，或者配置了错误的<resources>覆盖了默认配置。 - 部署路径问题：文件上传功能里写死的绝对路径，在部署机器上不存在，这是必炸雷。配置文件里用
@Value注入一个可以随时修改的属性，部署时改配置文件即可，不要硬编码路径。 - 外部依赖缺失：用
java -jar直接运行时如果提示NoClassDefFoundError，大概率是打包方式不对。检查pom里是否配置了spring-boot-maven-plugin，它可以把所有依赖打进同一个可执行jar里。
4.6 常见问题速查表
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 启动报端口占用 | 旧进程残留 | netstat+lsof查PID，杀掉占用进程 |
| 数据库中文乱码 | 连接串未指定utf8 | 连接URL加characterEncoding=utf8 |
| 登录后接口401 | token过期或拦截器未放行 | 检查token有效期、拦截器路径配置 |
| 文件上传报大小限制 | 默认1MB限制 | 配置文件调大max-file-size和max-request-size |
| 列表数据重复 | 分页插件未配置 | 注册MybatisPlusInterceptor分页插件 |
| 前端图片不显示 | 静态资源映射缺失 | 配置addResourceHandlers映射外部目录 |
| 接口返回null字段 | 前端没传这个字段或DTO映射问题 | 打日志输出入参，逐层排查 |
| 部署后页面404 | 前端路由history模式导致 | 后端配置forward到index.html，或改用hash模式 |
5. 毕设推进节奏、答辩加分点与整体复盘
5.1 四周落地计划表
很多人的毕设实际上只有一个月的时间窗口，这套系统最健康的开发节奏我建议这样分配：
| 时间段 | 工作内容 | 产出物 |
|---|---|---|
| 第1-3天 | 需求梳理、角色分析、数据库设计 | 数据库设计文档、建库脚本 |
| 第4-7天 | 环境搭建、项目骨架、登录认证、统一返回体 | 可登录的项目骨架 |
| 第8-15天 | 核心业务模块：村务公开、办事流程、意见箱、人口管理 | 主流程跑通 |
| 第16-20天 | 数据统计、权限细化、前端页面美化、联调 | 完整可演示版本 |
| 第21-24天 | 测试、修复Bug、补充边界处理（如空数据、异常提示） | 稳定版 |
| 第25-28天 | 写论文、画ER图、做答辩PPT、录演示视频 | 全套答辩材料 |
计划表看着简单，实际执行时最容易翻车的是第8-15天。前期骨架搭得再快，业务模块一旦塞进去，就是在不断和数据库表结构、前端交互较劲。我的经验是：登录和权限控制最多花3天，必须保住，后面的业务才有地基。
5.2 答辩时老师最爱问的十个问题
针对这类题目，答辩老师的问题出奇地一致，提前准备比临场发挥靠谱得多：
- 为什么选Spring Boot而不是传统的SSH/SSM？
- JWT和Session的差异是什么，为什么选JWT？
- 权限控制是怎么实现的，如何防止越权访问？
- 数据库有哪些表，核心表之间的关系怎么设计？
- 办事申请的状态流转是怎么实现的？
- 如果村民提交了重复申请怎么办？系统怎么限流或去重？
- 数据统计的SQL怎么写，大数据量下会有什么问题？
- 如何保证操作的追溯性？系统日志怎么设计的？
- 文件上传是怎么处理的？生产环境有什么不同？
- 系统如何部署，未来可以扩展哪些功能？
每个问题都不难，但回答时不要只答结论，要带上设计过程的考量。比如问“为什么选Spring Boot”，可以先说Spring Boot在自动配置、内嵌容器、生态丰富度上的优势，再补一句“考虑到毕设需要快速交付和稳定运行，选择它是综合权衡的结果”，这样回答就显得有思考深度，而不是背课文。
5.3 我做完这类项目之后的几点真实体会
第一个体会是：这类系统最大的工作量并不在写代码，而在梳理清楚了业务边界和角色权限之后，CRUD写起来是机械活，但业务边界想不明白才会不断返工。我见过太多人卡在“这个功能到底给谁用”这个问题上。先把一句话描述清楚系统是为谁做的、他的日常工作流程是什么样的，再动手，效率至少提升一倍。
第二个体会是：做系统一定要先跑通主流程，再补细节。很多同学喜欢一个模块一个模块挨着做，做到后面才发现核心链路没串通，比如办事申请审批完成了，公告或者统计模块并没有同步感知。建议每天发布一版能跑的代码，哪怕功能不全，至少主链路每天都在新增能力。
第三个体会是：演示数据要提前预制好。这个真的特别重要。答辩现场时间紧张，临时录入数据一旦出点小状况，心态很容易崩。最好准备几个固定测试账号，村民、村干部、乡镇管理员各一个，数据库里预先放好几十条公告、十几条办事申请记录、若干人口与资产信息。这样演示时每一步操作立即有数据反馈，界面满满当当，比现场从零添加好看得多。
还有一个小技巧收尾的时候提一嘴：答辩前记得先把上传文件目录建好，并保证程序启动时能自动创建。很多系统在别人电脑上第一次运行时，最容易挂在“本地没有C:/village-files目录”这种无声的错误上。提前演练一遍完整演示流程，比熬夜多写两个功能更有价值。
