不靠谱的糖饼前阵子帮一个学弟调后端，他的前后端分离精准扶贫管理系统跑不起来，SpringBoot 后端一启动就报数据库连接超时，Vue 前端登录接口直接 404。折腾了半个下午，问题出在 MySQL 8.0 的驱动配置和前端代理没配对。我当时就想，这类课设项目真的是年年都有、年年踩同样的坑。索性把整个项目从数据库设计、代码结构，到部署步骤和常见问题完整梳理一遍，给后面做 SpringBoot + Vue + MyBatis + MySQL 前后端分离管理系统的人留一份可直接对照的实战参考。
这个系统本身解决的是一个很实在的管理问题：困难群众信息、帮扶责任人、走访记录、帮扶计划、脱贫进度，这些数据如果停留在纸质档案和 Excel 里，查一个人要翻半天，统计一个片区更是灾难。系统化之后，管理员管权限，帮扶干部在线建档、填走访记录，领导看统计图表，整个流程就闭环了。对于想做课设、毕设，或者刚接触前后端分离开发模式想练手的人来说，这个项目是很典型的小而全案例，麻雀虽小，该有的知识点一个不缺。
1. 项目核心需求拆解：精准扶贫管理系统到底要管理什么
1.1 业务痛点：纸质档案与 Excel 管理模式的死穴
先聊业务，因为技术选型必须为业务服务。以往帮扶管理工作最大的问题是信息割裂。一个困难家庭的档案可能存在村委会的柜子里，帮扶干部的走访记录在自己的笔记本上，乡里的统计报表在另一个人的 Excel 里。等到需要汇总某个片区的脱贫情况时，要一层一层打电话要数据，回来还要手工核对身份证号、收入数字，错一处整个报表就废了。
另一个隐性痛点是过程无法追踪。谁去走访过、走访发现了什么问题、问题有没有跟进解决，这些信息如果不落到系统里，时间一长就变成一笔糊涂账。所以系统设计的第一目标不是“做一个漂亮的页面”，而是把“建档—帮扶—走访—退出”这条工作链路完整地数字化。
1.2 角色梳理：三类使用者的操作边界
设计权限之前先理清楚有哪些人用系统，这是管理系统的起点。这个系统里我划分了三类角色：
- 系统管理员：负责用户管理、角色权限分配、数据字典维护、菜单配置，相当于整个系统的运维者，原则上不参与具体的帮扶业务操作。
- 帮扶干部：负责困难家庭建档、填写走访记录、制定帮扶计划、上传证明材料，是系统的日常高频使用者。
- 部门领导：主要看各类统计报表、脱贫进度、区域分布数据，拥有大量的查询和统计权限，但不需要维护业务数据。
这个角色划分直接决定后端的接口权限设计、前端的菜单渲染和路由守卫拦截逻辑。你如果做课设，哪怕功能砍掉一半，这三个角色也得保住，因为评委基本都会问“不同角色登录后能看到什么、不能看到什么”。
1.3 核心业务流程闭环
把业务链路往前推一步，系统的主干流程是：管理员创建账号并分配角色 → 帮扶干部登录 → 为困难家庭建档（录入基本信息、致贫原因、家庭成员、收入情况）→ 制定帮扶计划 → 按计划开展走访并填写走访记录 → 定期更新收入数据 → 达到脱贫标准后提交脱贫评估申请 → 领导审批后完成“已脱贫”状态流转。
这个闭环后端实现时有几个关键点：建档时的行政区划联动选择（省市区三级）、走访记录与困难家庭表的关联写入、脱贫状态变更时的记录留痕。这些功能拆到技术上，就是多表关联查询、事务控制、分页列表、条件检索和简单的统计聚合。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 技术选型不是拍脑袋：为什么这套组合最适合课设与小型管理系统
2.1 SpringBoot：把打地基的时间省下来盖楼
在 SpringBoot 之前，搞一个 SSM 项目要先配置 web.xml、Spring 配置文件、MyBatis 配置文件、数据源、事务管理器，光是让项目成功启动就能劝退一半新手。SpringBoot 的核心价值是自动配置和内置容器，它把大量约定好的默认配置直接给你准备好，你要做的事情只剩在 application.yml 里填自己需要覆盖的配置项。
用一句生活化的话来说：Spring 是给你一套做菜的食材和配方，SpringBoot 是连炉灶、锅具、抽油烟机都帮你装好了，你直接开火就行。对于课设这种时间紧张的项目，省下来的配置时间可以用来打磨业务功能和写文档。
2.2 Vue 2 而不是 Vue 3？这里有一个经验主义的选择
我知道现在 Vue 3 已经是主流，但从找一个“能快速跑通、遇到问题能快速搜到答案”的课设项目角度，我仍然推荐 Vue 2 + Element UI 的组合，原因很实在：
- Vue 2 的教程、博客、CSDN 问答存量是 Vue 3 的好几倍，课设阶段你遇到 90% 的问题都能直接搜到现成的解决方案。
- Element UI 是专门为 Vue 2 设计的组件库，Element Plus 虽然功能更新，但和 Vue 2 不兼容，新手混装最容易出问题。
- 很多高校的教材和实验指导还停留在 Vue 2，用 Vue 2 写代码至少有人能指点。
当然如果你有 Vue 3 基础，用 Vue 3 + Vite + Element Plus 也完全可以，架构思路是一样的。核心要点是前后端通过 JSON 交互、通过 JWT 做身份认证、通过路由守卫控制页面访问权限，这些与 Vue 版本无关。
2.3 MyBatis：手写 SQL 带来的掌控感
MyBatis 被很多人吐槽 SQL 要自己写，但这种“笨办法”在管理系统里恰恰是优势。贫困家庭列表的多条件查询、贫困户信息和走访记录的多表联查、脱贫率的聚合统计，这些 SQL 手写能让你精确控制每一行查询逻辑，排查问题时也很清晰。
我见过不少用 JPA 的课设项目，简单 CRUD 确实爽，但一旦遇到复杂查询就得写 @Query 注解原生的 JPQL，很多人写不熟练就开始乱。而 MyBatis-Plus 又跳了一层，虽然它用起来很香，但如果你是做课设，答辩时被问到底层 SQL 是什么，用 MyBatis 手写 SQL 的你至少能讲清楚每一条查询是怎么回事。
2.4 最终版本组合参考
| 组件 | 推荐版本 | 说明 |
|---|---|---|
| JDK | 1.8 | 稳定且大部分学校机器都能跑 |
| SpringBoot | 2.7.x | 兼容 JDK8，配置方式成熟，教程多 |
| MyBatis | 2.3.x | Spring Boot 官方 starter，支持 XML 映射 |
| MySQL | 8.0.x | 免费、稳定，注意驱动类名与 5.7 不同 |
| Vue | 2.6.x | 与 Element UI 配套 |
| Element UI | 2.15.x | Vue 2 生态最成熟的 UI 库 |
| Node.js | 14.21.x | 对应 webpack4，避免高版本 Node 兼容问题 |
这套组合最大的特点是：每一层都有海量的踩坑记录。你在部署时遇到的任何报错，基本都能在网上找到同款。
3. 数据库设计：这套系统的表结构是管理系统的标准答案
3.1 RBAC 权限模型：用户、角色、菜单三件套
权限管理是所有管理系统的地基，我这里的做法是经典 RBAC 模型。最核心的是五张表：用户表、角色表、菜单表、用户-角色关联表、角色-菜单关联表。
用户表设计时有几个细节需要注意：
- password 字段长度要预留，如果使用 BCrypt 加密，密文长度是 60 位，varchar(64) 是安全的。
- 建议加 status 字段，用来禁用账号，而不是直接删除用户。
- create_time、update_time 用 datetime 类型，不要用 varchar，排序和查询性能都会更好。
菜单表的设计是前端动态路由的依据，常见的字段是 menu_name、parent_id、url、icon、order_num、type（目录/菜单/按钮），前端根据当前用户的角色查询可访问的菜单列表，再动态生成侧边栏。
3.2 核心业务表：困难家庭档案、帮扶计划、走访记录
业务主表是困难家庭表，我命名为 poor_household，字段设计如下：
- id：主键
- region_id：关联行政区划表，方便按区域统计
- householder_name：户主姓名
- id_card：身份证号，建索引，因为检索和去重都依赖它
- family_members：家庭成员数
- annual_income：年收入
- poverty_reason：致贫原因
- status：档案状态，建档、帮扶中、已脱贫、已返贫，用 tinyint 存储，用数字而不是中文，避免后期枚举值变更的麻烦
- is_deleted：逻辑删除标记，默认 0
走访记录表 help_record 是操作频繁的表，关键字段包括 household_id（关联困难家庭）、user_id（走访人）、record_content（走访内容）、visit_time（走访时间）、photo（图片路径）。这个表的查询场景通常是“某个困难家庭的走访历史”，所以 household_id 一定要建索引。
帮扶计划表 help_plan 则记录计划的目标、时间范围、当前进度，与困难家庭表是一对多关系。
3.3 核心建表 SQL 与关键设计说明
下面给出一段核心表结构的建表 SQL，你可以直接复制到 Navicat 或命令行执行：
sql复制CREATE DATABASE poverty_db DEFAUL