SpringBoot+Vue3前后端分离管理系统实战：从数据库到部署全解析

前阵子整理本地工作区时，翻出了这套扶贫管理系统的完整源码，想着正好很多人在折腾 SpringBoot + Vue3 的前后端分离项目，也经常有人问我这类管理系统从零搭建的思路，干脆把整个项目从需求拆解、数据库设计到前后端实现、部署坑点都拿出来讲透。这套系统虽然业务主题是扶贫管理，但它的架构方式和代码组织套路，放到任意后台管理系统里都能直接复用。

如果你正打算用 Java 技术栈做一套带权限、带流程、带报表的管理系统，或者你在准备面试时需要拿一个完整项目撑腰，这篇内容基本能覆盖你从设计到落地的所有环节。我尽量不聊空话，全部用这套系统里真实存在的表和接口来讲。

1. 项目概览与核心需求分析

1.1 为什么做一套扶贫管理系统

先交代场景。这个项目的初衷是帮基层做民生信息数字化，核心用户是乡镇或街道的帮扶干部，他们要管理辖区内困难群众的档案信息、帮扶走访记录、资金物资发放情况、帮扶项目的推进状态。在没有系统之前，这些信息通常散落在一张张 Excel 表和纸质台账里，数据更新滞后、多人协作困难、查询统计麻烦。系统要解决的就是三个问题：信息集中管理、操作有迹可循、数据能辅助决策。

从技术角度来说，这类业务是非常典型的管理信息系统，具备明确的对象管理、流程记录、汇总统计三个特征，所以它不需要复杂的微服务架构和分布式中间件，单体应用加前后端分离就是性价比最高的方案。整个系统我拆成了几个核心模块：农户档案、帮扶干部、帮扶计划、走访记录、资金发放、物资管理、项目管理和统计报表。每个模块都不是单纯的增删改查，它们之间有关联逻辑，比如新增一条资金发放记录时要校验受助人是否存在、金额是否在预算范围内，这些业务规则的实现就是后端接口设计的核心。

1.2 功能模块边界划分

我先用一张功能清单来展示这套系统的模块边界，方便后续讲数据库和接口时对得上号。

• 农户档案管理：维护家庭基本信息、致贫原因、收入情况、健康状态、劳动力情况等，支持档案的新增、修改、查询、导出。
• 帮扶干部管理：维护帮扶责任人的信息，以及一个干部负责了哪些农户，建立一对多的责任绑定关系。
• 帮扶计划管理：每个农户可以制定年度帮扶计划，计划包括帮扶措施、预期目标、时间节点，并且记录实际完成情况。
• 走访记录管理：干部每次入户走访的记录，包含走访日期、走访内容、现场图片、问题反馈。
• 资金物资管理：记录每一笔帮扶资金的申请、审批、发放状态，以及物资的入库、出库、结余情况。
• 统计报表模块：按区域、按年度、按类别统计帮扶人数、资金发放总额、走访覆盖率等指标，用图表展示。

从开发量来看，这六个模块加起来大概二十张表、六十多个接口，前端对应十几个页面组件，控制在两到三周的工作量比较合理。如果你是自己练手做毕业设计或者简历项目，这个规模也刚好能讲清楚设计能力，又不至于拖太久。

1.3 技术选型背后的逻辑

技术栈选的是 SpringBoot + Vue3 + MyBatis + MySQL，这套组合在近几年的后台管理系统开发里确实太常见了，以至于很多人忽略了它为什么合理。我在选型时主要考虑的是团队维护成本和招聘匹配度。

后端用 SpringBoot 是因为它把配置简化到了极致，内嵌 Tomcat 让部署变成了一个 jar 包的事，同时 Spring 生态的 starter 机制让整合第三方组件变得非常快。MyBatis 的选择有点争议，有人觉得 JPA 更省事，有人觉得 MyBatis Plus 效率更高，但我在这个项目里用原生 MyBatis 的理由是它的 SQL 完全可控，扶贫管理这种业务里有大量多表关联和条件统计查询，手写 SQL 能精确控制执行计划，排查问题时可以直接把 SQL 拿出来跑，这种直观的掌控感在业务报表开发里尤其舒服。

前端选 Vue3 是因为组合式 API 让代码组织更干净，配合 Vite 的开发体验确实比 Webpack 时代快一个量级。再加上 Element Plus 组件库，后台管理页面那些表格、表单、弹窗、分页等基础组件基本都齐了，开发效率非常可观。

数据库用 MySQL 不做多余解释，中小型管理系统的首选，稳定、够用、生态成熟，云厂商都有现成的 RDS 可以选。整套技术栈的组合逻辑是：业务不复杂但查询灵活，需要快速开发又有长期维护需求，单体 + 前后端分离就是最合适的形态。

2. 数据库设计与建模过程

2.1 核心表结构与字段设计

先强调一个观点：数据库设计决定了这个系统能走多远。很多同学做管理系统，表结构随手一建，后面接口写起来全是临时 join，维护成本特别高。我这套系统的表设计遵循三个原则：核心实体独立成表、业务关系通过外键或关联表表达、状态类字段用枚举值存储。

以农户档案表为例，这是整个系统的根表，其他模块基本都要引用它。核心字段包括家庭编号、户主姓名、身份证号、联系电话、所属区域、家庭人口数、耕地面积、主要收入来源、年人均收入、致贫原因、健康状况、住房情况、建档日期、脱贫状态等。身份证号要加唯一索引，其他常用查询字段要考虑加普通索引。

下面这段建表 SQL 是农户档案表的核心部分，可以直接参考：

sql复制CREATE TABLE `poverty_household` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
  `household_code` varchar(32) NOT NULL COMMENT '家庭编号',
  `householder_name` varchar(64) NOT NULL COMMENT '户主姓名',
  `id_card` varchar(18) NOT NULL COMMENT '身份证号',
  `phone` varchar(20) DEFAULT NULL COMMENT '联系电话',
  `region_code` varchar(20) NOT NULL COMMENT '所属区域编码',
  `family_member_count` int(2) DEFAULT NULL COMMENT '家庭人口数',
  `arable_area` decimal(10,2) DEFAULT NULL COMMENT '耕地面积(亩)',
  `income_source` varchar(255) DEFAULT NULL COMMENT '主要收入来源',
  `annual_income` decimal(12,2) DEFAULT NULL COMMENT '年人均收入(元)',
  `poverty_reason` varchar(255) DEFAULT NULL COMMENT '主要致贫原因',
  `health_status` varchar(32) DEFAULT NULL COMMENT '健康状况',
  `housing_condition` varchar(64) DEFAULT NULL COMMENT '住房情况',
  `poverty_status` tinyint(1) DEFAULT '0' COMMENT '脱贫状态: 0未脱贫 1已脱贫 2返贫监测',
  `archive_date` date DEFAULT NULL COMMENT '建档日期',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_id_card` (`id_card`),
  UNIQUE KEY `uk_household_code` (`household_code`),
  KEY `idx_region_code` (`region_code`),
  KEY `idx_poverty_status` (`poverty_status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='困难农户档案表';

几点设计心得。首先，household_code 和 id_card 必须做唯一约束，这是数据质量的底线，因为实际业务里身份证号填错会导致关联数据全部错乱。其次，region_code 用编码而不是直接存区域名称，是为了能按区域层级做统计和筛选，省市区三级编码的模糊查询就能支撑大多数报表场景。最后，扶贫状态字段用数字枚举，查表和索引都比字符串高效。

2.2 业务关系表的设计思路

除农户档案这类实体表外，系统还需要一些关联表和业务记录表。帮扶干部和农户是多对多的关系，一个干部负责多户，一户也可能有多名干部协同帮扶，所以需要一张中间表来维护关系：

sql复制CREATE TABLE `support_binding` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `cadre_id` bigint(20) NOT NULL COMMENT '帮扶干部ID',
  `household_id` bigint(20) NOT NULL COMMENT '农户ID',
  `bind_time` date DEFAULT NULL COMMENT '绑定时间',
  `unbind_time` date DEFAULT NULL COMMENT '解绑时间',
  `status` tinyint(1) DEFAULT '1' COMMENT '状态: 1生效 0失效',
  PRIMARY KEY (`id`),
  KEY `idx_cadre_id` (`cadre_id`),
  KEY `idx_household_id` (`household_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='帮扶责任绑定表';

这里有个容易被忽略的细节：绑定关系是有时效性的。如果只存当前状态，历史数据就丢了，而民政审核时经常要查"2023年这个农户由谁负责"，所以绑定表里必须有生效时间和失效时间，用状态位标记当前是否生效。这个思路在做人员转派、区域调整等业务时非常重要。

再比如资金发放记录表，它不只是记录发了多少钱，还要记录这笔钱对应哪个农户、哪个计划、审批到哪一步、由谁操作。关键字段包括关联的农户 ID、计划 ID、发放类型、金额、发放方式、审批状态、操作人、审批意见。这类记录表的共同特征是"数据只增不改"，即使审批被驳回，也要保留完整轨迹，不能物理删除。

2.3 针对报表查询的适度冗余

我在设计后续迭代时发现，按区域统计扶贫数据的查询会涉及农户表、帮扶计划表、资金表的多表关联，如果每次统计都做多次 join，数据量上来后响应会明显变慢。于是在部分统计表中做了一些冗余，比如在资金发放明细中直接保存区域编码和年度字段，这样统计时就能直接按这两个字段分组，避开回表查询。

冗余和反规范化的取舍，是 SQL 优化里最大的考点。对于后台报表场景，读多写少，冗余字段带来的查询性能提升远大于存储开销。另外，我所有的金额字段都用 decimal，而不是 float 或 double，这一点必须特别强调，涉及资金的数据用浮点类型会导致精度丢失，这在业务上是完全不可接受的错误。

3. 后端 SpringBoot + MyBatis 的实现细节

3.1 工程结构与分层设计

后端工程我采用标准的 maven 单体多模块结构，但实际代码分包是单一应用内按业务模块划分，没有强行拆 maven 多模块。为什么？因为这套系统的代码量，一个 SpringBoot 应用完全扛得住，拆模块反而增加构建复杂度。真正的分层在包结构上体现：

• controller：接收请求、参数校验、返回统一结构。
• service：接口 + 实现类，组织业务逻辑和事务边界。
• mapper：MyBatis 的接口层，定义数据库操作方法。
• entity：数据库实体映射。
• dto：前端交互的数据传输对象，避免直接暴露实体。
• vo：视图对象，用于接口返回给前端的数据结构。
• config：框架配置类，比如数据源配置、MyBatis 配置、拦截器配置。
• common：统一返回结果、异常处理、工具类。
• constant：业务常量定义，比如状态枚举、字典常量。

这个分层的好处在哪呢？最直观的是多人协作时大家开发互不干扰，你改 service，我改 controller，冲突概率很低。其次是对面试或者项目答辩来说，分层清晰本身就是一个加分项，说明你具备工程化意识而不是随手写脚本。

3.2 统一返回结构与异常处理

前后端分离项目的第一个硬规范就是接口返回结构必须统一。我的统一返回类设计如下：

java复制@Data
public class Result<T> {
    private Integer code;
    private String message;
    private T data;

    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMessage("success");
        result.setData(data);
        return result;
    }

    public static <T> Result<T> error(String message) {
        Result<T> result = new Result<>();
        result.setCode(500);
        result.setMessage(message);
        return result;
    }
}

很多初学者喜欢在 Controller 里直接返回实体类，返回结构五花八门，前端联调时每个接口都要单独适配，非常浪费时间。统一返回结构后，前端 Axios 拦截器只需要判断 code 字段即可全局处理错误提示和登录失效跳转。

异常处理方面，我用 @RestControllerAdvice 做了全局异常拦截，业务异常、参数校验异常、数据库操作异常分别返回不同的 code 和提示信息。这样 Service 层就可以大胆抛异常，不需要每层都写 try-catch。还有一个细节，全局异常处理器一定要把完整异常栈打到日志里，但返回给前端的 message 要谨慎，不要把数据库异常信息直接暴露出去，避免信息泄露风险。

3.3 MyBatis 动态 SQL 与缓存的实战

先做个小提醒：MyBatis 的缓存机制在实际项目里坑不少，网上搜"mybatis 缓存"能找到很多讨论，很多人被一级缓存、二级缓存的概念绕晕。我的建议是，这种业务管理系统默认把二级缓存关掉，一级缓存虽然默认开启，但在跨方法调用时也帮不上什么忙。

为什么这么说？MyBatis 的一级缓存是 SqlSession 级别的，在 Spring 整合环境下，mapper 对象的生命周期被管理，只有在同一个事务内的多次查询才会命中缓存，实际业务中触发场景很少。二级缓存是 namespace 级别的，如果开启了但没处理好脏数据，一个表更新后另一个表的缓存没失效，数据就陈旧了。与其花大量精力配置和调优缓存环境，不如把 SQL 本身写高效，配合 MySQL 自身的查询缓存，性能足够了。如果后续需要更强性能，再上 Redis 做针对性缓存。

动态 SQL 是 MyBatis 最实用的能力。前端列表页的筛选条件千变万化，手写 SQL 拼接容易出 SQL 注入，MyBatis 的动态标签就是做这事的。这段代码展示了我用多条件查询农户档案的写法：

xml复制<select id="selectHouseholdList" resultType="com.example.entity.PovertyHousehold">
    SELECT * FROM poverty_household
    <where>
        <if test="name != null and name != ''">
            AND householder_name LIKE CONCAT('%', #{name}, '%')
        </if>
        <if test="regionCode != null and regionCode != ''">
            AND region_code LIKE CONCAT(#{regionCode}, '%')
        </if>
        <if test="povertyStatus != null">
            AND poverty_status = #{povertyStatus}
        </if>
    </where>
    ORDER BY create_time DESC
    LIMIT #{offset}, #{pageSize}
</select>

<where> 标签会自动处理首行 AND 的问题，<if> 标签做条件判断。这套写法在管理系统的所有查询列表里通用，字段多也不用怕框架枯竭。还有一个冷门细节，LIKE 查询时用 CONCAT('%', #{name}, '%') 而不是直接在参数里拼好 %，这样可以避免 SQL 注入，也让索引使用得更可控。

3.4 事务控制与业务校验

帮扶资金发放这类写操作必须加事务。业务规则没有以前想的那么简单，比如发放资金时要同步更新农户的收入记录，如果资金记录插入成功、收入记录更新失败，事务不一致就会导致台账和明细对不上。我的事务使用方式很简单，在 Service 实现类的方法加 @Transactional 注解，但有一个重要的注意点：事务要在类的公开方法上，并且不能被同类内的其他方法自调用绕过。

在方法内部和调用它的方法不在同一个类的情况下，@Transactional 才能正常代理生效。如果类内部的 A 方法调用了同类 B 方法，B 上的事务注解不会生效，这其实是 Spring AOP 代理的一个经典注意点，面试也经常考。解决方式要么把 B 方法单独拆到另一个 Service 类里，要么在 Bean 自身代理上操作。

参数校验的话，按照最佳实践来说应该统一用注解式校验，比如在 DTO 字段上加 @NotNull、@Size 等注解，Controller 方法参数上加 @Validated，这样代码看起来非常干净。查询列表的话，分页参数建议用 PageHelper，这是一款非常成熟的 MyBatis 分页插件，用法简单，导入依赖后调用 PageHelper.startPage(pageNum, pageSize)，紧接着的查询就会被自动分页。

4. 前端 Vue3 开发与联调实践

4.1 Vite 工程搭建与目录规划

前端工具链我推荐用 Vite，官方工具生成 Vue3 + TS + Vue Router + Pinia 项目很方便。工程建好后，目录结构我一般按功能做区分，管理系统的页面通常层级固定，目录清晰，页面组件、路由配置、状态管理、API 请求、工具函数各归其位。

bash复制npm create vite@latest poverty-admin

创建后按需安装依赖：

bash复制npm install
npm install vue-router@4 pinia axios element-plus

为方便开发，Vite 的 vite.config.js 里配好开发服务器代理，把 /api 的请求转发到后端的 8080：

js复制server: {
  port: 3000,
  proxy: {
    '/api': {
      target: 'http://localhost:8080',
      changeOrigin: true
    }
  }
}

这样处理之后，前端所有请求都写 /api/xxx，开发环境不用考虑跨域问题。后端接口路径前缀统一加 /api 即可。生产环境部署时，再让 Nginx 做同样路径的代理转发，整个链路就通了。

4.2 核心页面组件的套路化写法

管理系统页面的前端开发，说白了就是表格页、表单页、详情页的组合。表格页我直接用 Element Plus 的 el-table，配合 el-pagination 做分页，数据请求统一封装在 api/household.js 这类模块里。这里展示一个典型的数据请求封装方式：

js复制import request from '@/utils/request'

export function getHouseholdList(params) {
  return request({
    url: '/api/household/list',
    method: 'get',
    params
  })
}

utils/request.js 里封装 Axios 实例，统一设置基础 URL、请求超时时间、请求拦截器添加 token，响应拦截器根据 code 字段做统一处理，比如 code 为 401 时跳转登录页，code 为 500 时弹出错误提示。

js复制service.interceptors.response.use(
  (response) => {
    const res = response.data
    if (res.code !== 200) {
      ElMessage.error(res.message || '请求失败')
      return Promise.reject(new Error(res.message))
    }
    return res
  },
  (error) => {
    ElMessage.error(error.message || '网络异常')
    return Promise.reject(error)
  }
)

表单页则使用 el-form 加 rules 校验规则，提交前统一做一次 validate。弹窗和表格的组合是后台系统最常见的开发模式，熟练后这类页面几乎不用动脑子，套模板即可。要注意的是 Vue3 中组合式 API 的一个好习惯，把同一个模块的响应式状态和操作方法放在一起，用 ref 和 reactive 管理数据，逻辑才能清晰。

4.3 权限控制与路由守卫

管理系统的权限控制是面试的高频问题，这个项目里我用的是非常经典的 RBAC 模型：用户-角色-菜单权限，前端登录后拿到当前用户拥有的菜单和按钮权限码，动态生成路由。Vue Router 的 beforeEach 守卫里判断 token 是否存在、用户信息是否已加载、当前路由是否在权限列表中：

js复制router.beforeEach((to, from, next) => {
  const token = localStorage.getItem('token')
  if (!token) {
    if (to.path === '/login') {
      next()
    } else {
      next('/login')
    }
    return
  }
  if (!userStore.userInfo) {
    userStore
      .fetchUserInfo()
      .then(() => {
        next({ ...to, replace: true })
      })
      .catch(() => {
        userStore.logout()
        next('/login')
      })
    return
  }
  next()
})

这里有个实用经验：动态路由根据后端返回的菜单逐条 addRoute，刷新页面时要重新注入路由，否则页面一刷新就是空白。针对这个情况，我在 permission.js 里做了一个标记，每次刷新后重新加载用户信息和路由表，用 location.reload() 或 router.replace 的方式处理，基本能保证刷新不掉链子。

4.4 图标与表格联动的细节优化

现在热词里经常看到有人问 Vue3 后台管理系统里的 tabs 标签页样式、pxtorem 对 echarts 不起作用这类问题。说实话这类细节在我们这个项目里也踩过。首先，ECharts 图表组件的容器在 pxtorem 方案下确实经常出现图表尺寸异常，因为 ECharts 在初始化时读取的是容器像素宽度，如果单位被转换，计算结果会偏离预期。解决方案是给图表容器显式设置宽度，或者初始化时用 window.innerWidth 做参照。其次，tabs 标签样式适配的问题主要是需要手动覆盖 Element Plus 的样式变量，在 :root 里定义主题色变量后对组件深层样式做调整。

图表部分，我在统计报表页直接用了 ECharts 的组件封装，柱状图展示各年度帮扶资金发放情况，饼图展示致贫原因分布。前端图表开发的重要经验是先和后端约定好数据结构，比如返回一个 [{name: '疾病', value: 32}, {name: '残疾', value: 18}] 这样规整的数据，前端直接映射到 ECharts 的 series 数据，省去大量转换工作。

5. 启动运行与环境配置指南

5.1 本地开发环境搭建

这套系统本地跑起来需要准备四样东西：JDK 8+、Maven 3.6+、Node.js 16+、MySQL 5.7 或 8.0。如果你电脑上还没装 MySQL，网上搜"mysql 安装教程"或"mysql 安装配置教程"能找到很多图文步骤，核心就是下载、解压或安装、初始化 mysqld --initialize-insecure、服务启动、修改 root 密码。我建议直接用 MySQL 8.0，性能和默认字符集都比 5.7 有优势。注意安装时选择不区分大小写的排序规则，可以避免一些 Linux 环境下因为大小写敏感导致的表找不到问题。

数据库建好后执行项目里的 sql/init.sql 脚本，一次性建库建表，默认数据也插好。然后在 application.yml 里配置数据源信息：

yaml复制spring:
  datasource:
    url: jdbc:mysql://localhost:3306/poverty_aid?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false
    username: root
    password: yourpassword
    driver-class-name: com.mysql.cj.jdbc.Driver
mybatis:
  mapper-locations: classpath:mapper/*.xml
  type-aliases-package: com.example.entity
  configuration:
    map-underscore-to-camel-case: true

map-underscore-to-camel-case 这个配置非常重要，开启后数据库的 householder_name 字段能自动映射到实体类的 householderName 属性，省掉大量 resultMap 的编写。配置好后，后端启动访问 http://localhost:8080/api/ping 验证是否正常，前端在项目目录执行 npm run dev，访问 http://localhost:3000 即可进入系统。

5.2 常见启动问题与排查清单

我在开发和给别人排错的过程中，总结了一些常见问题的排查方向，整理成表格方便对照：

最后一条是前后端分离项目的经典坑，本地开发 Vite 没问题，一旦部署到 Nginx，history 模式路由刷新就报 404，必须加上 fallback 配置。这是生产环境部署的必备配置。

5.3 部署与上线注意事项

上线部署我是用前后端分离的标准方式：后端打 jar 包，前端 npm run build 生成 dist 目录，Nginx 托管静态文件，同时代理 /api 请求到后端服务。为了方便维护，我在 Nginx 里配置了这样一段核心的 server 块：

nginx复制server {
    listen 80;
    server_name yourdomain.com;

    location / {
        root /var/www/poverty-admin/dist;
        index index.html;
        try_files $uri $uri/ /index.html;
    }

    location /api/ {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

后端 jar 包建议用 nohup java -jar poverty-admin.jar > app.log 2>&1 & 方式后台启动，日志输出到文件方便排查。另外，生产环境有两点值得重点注意：一是数据库密码不要明文写在配置文件里，可以用环境变量或配置中心动态注入；二是数据要定期备份，扶贫系统的数据涉及民生台账，备份加恢复演练都很有必要，最好加一个定时任务把数据库 dump 到异地存储。

6. 项目亮点与可扩展方向

6.1 填得了坑也讲得出亮点的设计

这个项目在面试、答辩或者简历里能作为亮点讲的点有几个。首先是数据校验和事务控制的严谨性，资金模块每一笔操作都有完整的事务边界和操作记录，这在管理系统里天然比单表 crud 高一档。其次是动态查询的实现，列表页的多条件组合查询全部走 MyBatis 动态 SQL，没有一处拼字符串，安全性和可维护性都更有保证。再者就是前端权限控制的完整性，登录、路由守卫、按钮权限、菜单权限一条龙闭环，这是后台系统最标准的加分项。

系统的可扩展方向也很明确。如果需要更强的扩展性，后续可以做多维度的扶贫成效分析，将脱贫率的变化趋势与帮扶措施关联起来，用定时任务生成统计报表。如果需要接外部系统，比如对接财政系统或民政数据平台，可以在现有的接口设计上直接加一层 Open API。

6.2 一套代码通用管理系统的复用思路

最后聊一点我认为更重要的东西。这套系统的代码结构实际上是通用后台管理系统的模板，把扶贫相关的实体类和业务逻辑替换成其他领域，相当于换个皮就能用。我后来做检查管理、办公用品管理等系统时，沿用了这套工程骨架，只改了数据库表、实体类和接口逻辑，前端表格表单部分基本是复制后改字段名，开发效率非常高。

在这里我也建议正在学 Java 全栈的人，不管用不用这套代码，一定要拿一个完整的业务场景练手，重点体会数据库关联设计、接口分层、前后端联调这三件事，这是企业开发中最核心的能力。光看教程、啃面试题，撑不起一个能落地的项目。

7. 最后的实际操作心得

这个项目开发过程中有几个踩过的坑值得单独拿出来讲一讲。

MySQL 字符集从来没像现在这么重要。以前很多老系统用 latin1，一旦遇到中文姓名和地址，数据乱码会变得非常麻烦。所有表我都统一用 utf8mb4，在连接串里也显式指定 characterEncoding=utf8，这套配置在项目初期就要定好，等数据表建完再改字符集，涉及数据转换成本极高。

关于 MyBatis 的单引号和查询条件，网上经常看到有人说"mybatis 单个数字字符比较"有问题，这大概率是查询条件用 AND status = #{status} 传了字符串 '0'，前端传过来的是数字 0，参数类型不一致导致 SQL 结果异常。经验是前端请求统一把状态参数转成数字再传，后端在 DTO 上用好 @NotNull 和类型转换校验，两个方向同时把口径定好，就不会出这种问题。

关于 SpringBoot 版本，我建议新手不要选太高的版本，3.x 的版本对 JDK 版本有严格要求，需要 JDK 17 以上，同时很多老依赖的兼容性还没跟上。这个项目我用的是 SpringBoot 2.7.x，对应 JDK 8，最稳妥的组合。如果你只是想快速跑起来，直接搜"idea 创建 springboot 项目"，选 Spring Initializr 脚手架，填好参数一键生成，省事也规范。

日志这件事我多说一句。管理系统在上线后一半以上的排查时间消耗在日志上，日志打得不好，出问题完全抓瞎。我在项目中要求所有 Service 层的关键方法必须打日志，包括入参、操作人、操作结果，异常信息用 log.error 记录完整堆栈。这个习惯在复盘问题时帮了大忙。希望这些经验能让你在搭建同类系统时少走一点弯路，直接上手就把代码写到能上线、能展示的水平。