Spring Boot非遗管理系统毕设实践：功能模块与数据库建模全解

把话放在前面：如果你的毕设题目叫《基于Spring Boot的普洱市非物质文化遗产管理系统》，或者只是把地名换成了别的城市，建议你不要把它当成一个普通的“增删改查管理系统”来做。非遗领域的核心难点从来不是写几个接口，而是项目类别、名录级别、申报状态、传承人关系、图片视频素材这些逻辑搅在一起之后，你怎么让数据关系不乱，让管理员愿意用，也能在答辩时把业务逻辑讲清楚。

我做过一段时间非遗资料的数字化整理，最初也是拿Excel做底账，后来用Spring Boot复刻这套东西时发现，直接照搬Excel的字段设计远远不够，必须往流程、权限和素材关系上再走一步。这篇文章就围绕“普洱市非物质文化遗产管理系统”这个计算机毕业设计题目，从需求拆解、模块划分、Spring Boot工程配置、数据库建模、核心代码实现、部署演示到论文答辩，完整过一遍，适合刚拿到题目还没有清晰思路的同学，也适合下载过相关源码但讲不清系统逻辑的同学。

1. 先想清楚：非遗管理系统里的“非遗”到底要管理什么

1.1 项目的分类、级别和状态不是三个普通字段

很多管理系统，比如图书管理、学生管理，核心对象相对单一，拿一本书和一个学生做增删改查就够了。但非遗这个对象要复杂得多。它首先要区分类别，民间文学、传统音乐、传统舞蹈、传统戏剧、曲艺、传统美术、传统技艺、传统医药、传统体育游艺与杂技、民俗，这些类别是官方名录里非常标准的分类维度，和普通后台的“随便分个类”不是一回事。

其次是级别。非物质文化遗产有县级、市级、省级、国家级等不同层级，一个系统如果只保存“级别”这个下拉框选项，很容易忽略“不同级别之间的申报关系”。很多项目是先申报县级，再逐级往上申报的，如果只记录当前最高级别，那审批记录、历史级别、公布时间这些关键信息就丢了。

第三是状态。一个非遗项目从发现线索到录入系统，中间有申报、初审、专家评审、公示、公布、归档等环节。这些状态不是流程结束后就不变的，后续可能因为项目保护情况变化、传承人变更而重新进入审核流程。所以设计系统时，要把类别、级别、状态当成三维交错的业务属性，而不是三个普通字段。数据库表结构如果只做成“编号、名称、简介”的极简模式，后面一进入真实业务场景就会卡壳。

1.2 业务流程闭环：系统不能只做“结果登记”

给非遗类管理系统做设计，最忌讳的就是只做一个录入页面，让管理员把一份非遗项目档案直接填进去。真实业务从来不是一次性录入的，而是一个持续流转的过程。

以一个市级非遗中心收到的线索为例：先有一位非遗爱好者或者保护单位提交一份推荐材料，管理员初审后认为有潜力，要补充调研资料和影像记录，然后进入专家评审，评审通过后走公示流程，最后才会作为某个级别的非遗项目正式建档。

这个过程在做毕业设计时完全可以简化，但不能不做。哪怕只是用“状态机”的思路在业务表里加一个status字段，再单独建一张审核记录表，让每一步都有操作人、操作时间、审核意见，整个系统的业务完整度就会明显提上来。答辩时老师问你“这个系统除了增删改查还有什么”，你可以很顺地把申报到公布的流程讲出来，这是系统的重要亮点之一。

我在帮地方整理底账的时候，发现很常见的一个情况是，不同团队上报的同一个项目，名称写得五花八门。比如同一个民俗活动，有人登记“XX节”，有人登记“XX习俗”，还有人把地方别称写上去。这就引出一个容易被忽略的设计点，项目表里要加一个“别名/曾用名”字段，或者单独做别名表，方便后续搜索和查重，避免同一个非遗项目在系统里出现多条重复记录。这一点虽然技术难度不大，但能让系统设计显得懂业务，非常推荐你写进需求分析和数据库设计里。

1.3 结合地域特色做演示数据会更有冲击力

系统本身是通用的，但你的题目里带了“普洱市”三个字，这一层地域色彩如果利用好，会让系统在众多课程设计、毕业设计中更有辨识度。

普洱当地有普洱茶制作技艺这类传统技艺，也有佤族木鼓舞、傣族织锦技艺、拉祜族芦笙舞、民俗节庆类项目等。初始化数据库时，与其塞一堆“张三的剪纸”、“李四的木工”，不如用这些真实的、有地域代表性的非遗名录来填充演示数据。

演示的时候不要只是说“我这里录入了十条数据”，而是说“目前系统里录入的项目涵盖了传统技艺、传统舞蹈、民俗三大类，其中普洱茶制作技艺按国家级非遗项目维护了申报材料、保护单位信息以及视频图片资源，传承人模块也建立了对应的关联档案”，这个表述对答辩效果的加成非常大。信息层面只需要做到“逻辑正确，不强行编造权威结论”，作为演示数据完全够用。

2. 功能模块：不要做成平台，要做成能自洽的闭环系统

2.1 前台门户与后台管理要拆开考虑

这类管理系统最常见的技术形态是前后端分离，前端展示给普通访客，后台给管理单位使用，不建议你把所有功能都塞进一个后台，然后只做几张表格。

前台部分可以设计成：首页轮播、非遗项目分类展示、项目检索和详情页、传承人风采、最新资讯动态、活动通知与预约报名、站内留言或咨询入口。前台的目标是让访客能通过系统知道什么是非遗，当地有哪些非遗项目，有哪些传承人，最近有什么传承活动可以参加。

后台部分则要面向管理员完成核心管理工作：非遗项目管理、传承人管理、传习所或保护单位管理、申报审核管理、资讯与轮播图维护、活动发布、留言处理、字典参数维护、系统用户与权限管理、数据统计等。前台和管理端的数据是同一个库，你在描述系统架构时，要明确说明这个数据从录入到发布的完整路径，而不是让管理员每次改完内容还要手工去改前端页面。

2.2 角色权限决定模块边界

关于角色的划分，要依据系统使用场景来定，而不是抄网上的“超级管理员、普通管理员、普通用户”三段式模板。对于非遗管理系统，建议你用下面这组角色更贴近实际：

• 超级管理员：一般是市级非遗保护机构的技术管理员，拥有菜单管理、用户配置、全局数据维护等全部权限。
• 内容管理员：面向区县或保护单位的业务人员，可以维护本区域范围内的非遗项目和传承人资料，能发起申报但不能直接公布。
• 注册用户：面向公众，可以浏览信息、报名参加传承活动、在详情页留言。

这里不需要把权限设计得特别复杂。毕业设计阶段，不建议直接引入Spring Security做全套RBAC权限模型，因为配置过程繁琐，如果掌握不好反而容易被追问。可以在用户表里设计一个角色字段，后端提供一个登录拦截器，对“/admin/**”接口做登录校验，管理员接口里再判断当前用户角色是否匹配。这样前后台权限边界清晰，代码量也不至于把毕业设计拖垮。

2.3 功能优先级：先守住主干，再谈加分项

我在给不同类型毕业设计做拆解时，经常看到学生花大量时间去做大屏数据可视化、图像识别等看起来很新的功能，结果主干功能还没跑通。毕业设计核心目标应该是“业务闭环完整、技术应用合理、答辩经得起问”，而不是功能数量大比拼。

所以排序应该是这样的：

P0优先级，非遗项目管理的完整CRUD和分页搜索、项目分类维护、用户登录注册、基础角色权限。这些功能决定了系统能不能作为“管理系统”跑起来。

P1优先级，传承人管理、申报审核流程、图片和视频上传、前台分类展示和信息详情。这些能让业务从“录入”走向“展示和闭环”。

P2优先级，资讯管理、活动预约、轮播图管理、评论留言、统计图表。这些是让系统看起来完整、演示效果更好的功能，但有时间再做，不要一上来就陷进P2功能里。

把P0和P1先做完，哪怕后面时间紧张，论文里的功能结构也已经完整，可以交了。

3. 技术选型：Spring Boot 2.7.18是我给当前毕设的默认答案

3.1 Spring Boot版本为什么要压着别乱升

最近总看到有人在群里问“springboot版本太高”导致项目跑不起来，这个问题在毕业设计里特别常见。很多同学从某个博客抄了一份配置，发现对方的Spring Boot是2.2，自己新建项目默认选了3.2，结果一堆包名对不上、依赖版本冲突，项目还没写代码就开始劝退。

我的建议是：只要你的运行环境是JDK8，老老实实用Spring Boot 2.7.18，这是2.x线最后一个稳定维护版本。Spring Boot 3.x全面切换到JDK17和Jakarta命名空间，很多老毕业设计教程里的import javax.servlet类都要改成jakarta.servlet，数据库驱动、MyBatis-Plus版本也全部要跟着升级，没必要给自己挖这个坑。

如果你的项目初始模板已经是Spring Boot 3.x，最简单的方式是在Spring Initializr生成项目时，把Java Version选成8，Spring Boot版本恢复2.7.18，然后刷新Maven依赖再执行mvn clean compile。注意看pom.xml里parent版本是否真的换成了2.7.18，JDK编译参数也要对应调整。

3.2 技术清单与职责定位

下面这份是我比较推荐的毕设技术组合，既不完全落伍，也不会给自己增加太多不可控的复杂度：

前后端技术栈里，如果完全没接触过Vue，也可以选择在Spring Boot里用Thymeleaf模板引擎配合Bootstrap和Layui渲染后台页面，一条技术链路下来代码更少，部署也更容易。但通常毕设系统会更偏向“Spring Boot + Vue前后端分离”，做起来后维护和截图展示都方便，你有时间学习基础用法的话，Vue是更合适的路线。

3.3 工程结构与核心配置参考

在包结构设计上，我建议建立一个顶层包，比如com.puer.ich，里面按职责分层，不要按页面堆类。一个基本功扎实的包结构大致是这样的：

text复制com.puer.ich
  ├─ common          // 统一返回体、全局异常、常量、工具类
  ├─ config          // 拦截器配置、跨域配置、上传配置
  ├─ controller      // 接口层
  ├─ service         // 业务逻辑层
  ├─ mapper          // MyBatis Mapper接口
  ├─ entity          // 数据库实体
  ├─ dto             // 前端传参或返回的视图对象
  └─ IchApplication.java   // 启动类

application.yml是整套配置最容易出错的地方，核心配置可以参考下面这个模板，字符集、时区、上传大小都要提前设置好：

yaml复制server:
  port: 8080

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/ich_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai
    username: root
    password: 123456
  servlet:
    multipart:
      max-file-size: 50MB
      max-request-size: 200MB
  jackson:
    date-format: yyyy-MM-dd HH:mm:ss
    time-zone: Asia/Shanghai

mybatis-plus:
  configuration:
    map-underscore-to-camel-case: true
    log-impl: org.apache.ibatis.logging.stdout.StdOutImpl
  global-config:
    db-config:
      logic-delete-field: deleted
      logic-delete-value: 1
      logic-not-delete-value: 0

如果MySQL连接报Public Key Retrieval错误，可以在url后面加allowPublicKeyRetrieval=true。这些参数用文字记录在项目说明文档里，答辩时也可以提你对常见环境问题的处理经验，属于加分细节。

4. 数据库建模：状态、关联关系、多媒体资源是最容易翻车的三个点

4.1 非遗项目主表：不要把简介做完就收工

非遗产项目表是整套系统的核心业务表，需要至少满足以下信息维护：项目名称、项目别名、所属非遗类别、项目级别、所属地区、保护单位、代表性传承人、公布时间、历史沿革、项目简介、封面图URL、当前状态、浏览量等。

如果用字段表格来表达，这份主表的核心字段可以划分得很清楚：

有了这张表，前台展示和后台管理的结构才立得住。

4.2 传承人不是项目的一个字符串字段

最容易犯的错误是在非遗项目表里设计一个“代表性传承人”字段，直接把所有传承人姓名用逗号拼接成一个字符串。这样做确实很简单，但后续根本没法统计“这个传承人负责了几个项目”或者“某个传承人关联了哪些类别”，演示时一旦老师问你“怎么查询一位传承人对应的所有非遗项目”，系统就露馅了。

所以传承人和项目之间应该建立多对多的关联表，比如project_inheritor表，保存项目ID和传承人ID，同时可以附带传承人级别、传承时间、认证批次等信息。独立设计传承人表也很关键，传承人本身包含姓名、性别、出生年份、民族、传承类别、工作单位、肖像照片、从艺经历、师承关系等属性，只有独立成表才能保持系统数据的规范和可扩展性。

4.3 审批记录单独建表，状态字段只是冗余

你可以在非遗项目表里留一个status字段，用来快速查询和展示当前状态，但真正的审核底细必须单独放在一张operation_record或者audit_record表里。

这张审核记录表的字段要包含：业务类型、业务表ID、提交人、提交时间、审核人、审核时间、审核前状态、审核后状态、审核意见。这样从项目线索录入到最终公布的每一步都有迹可循，答辩时能讲出完整的故事。

如果不做审核记录表，只是在项目表里把审核结果覆盖上去，那历史审核意见就全部丢失了。数据库设计答辩题里，“审批流程如何保证可追溯”是一道经典大题，提前做好记录表设计，这个问题就被你拿捏住了。

4.4 图片视频资源：尽量做通用关联表而不是堆一堆URL字段

做非遗管理系统时，每个项目可能有多张图片、视频、PDF材料甚至音频。在数据表里预留picture1、picture2、video1这种字段是很糟糕的方案，新加一张图片就要改表结构，非常不工程化。

推荐的方案是单独建一张resource表，包含resource_type，比如1表示图片、2表示视频、3表示文档，加上关联业务类型、关联业务ID、资源名称、资源URL、显示顺序、上传时间。这样非遗项目、传承人、资讯等任何业务都可以复用同一套资源管理机制。前台上传和展示时只需要按business_type和business_id查询资源列表。

做一个项目资源底账的多媒体信息存档，这套通用资源表会比普通的后台系统显得专业很多，而且后端实现同样简单，只需要在项目删除时同步删除关联资源，或做一次级联删除的逻辑。

5. 代码实现阶段：怎么把增删改查写出工程感

5.1 统一返回体设计，让每个接口风格一致

很多毕设项目里每一个Controller都直接返回Map或者直接把数据往JSON里塞，状态码和消息五花八门，这是比较大的代码风格问题。我习惯在项目一开始就写一个通用的返回体类，比如统一定义Result对象。

实际Controller中，返回风格会是这样：

java复制@PostMapping("/add")
public Result<String> add(@RequestBody Project project) {
    projectService.saveProject(project);
    return Result.success("保存成功");
}

这个简单封装的收益早期不明显，但你要在论文里写“系统采用统一响应结构，实现前后端数据交互规范统一”，同时全部接口都遵守同一套约定，技术上确实做到了。前端也非常好处理，只需判断返回体里的code值即可，不需要逐个接口解析。

5.2 分页搜索接口：MyBatis-Plus条件构造器要配合VO使用

非遗项目列表页是后台使用最频繁的页面，通常需要按项目名称模糊搜索，按非遗分类下拉筛选，按级别筛选，按状态筛选。用MyBatis-Plus时，可以直接使用LambdaQueryWrapper条件包装器，避免手写大量动态SQL拼接。

代码的大致模式是这样的：

java复制public PageResult<ProjectVO> queryProjectPage(ProjectQuery query) {
    LambdaQueryWrapper<ProjectEntity> wrapper = Wrappers.lambdaQuery();
    wrapper.like(StrUtil.isNotBlank(query.getProjectName()),
            ProjectEntity::getProjectName, query.getProjectName());
    wrapper.eq(query.getCategoryId() != null,
            ProjectEntity::getCategoryId, query.getCategoryId());
    wrapper.eq(StrUtil.isNotBlank(query.getProjectLevel()),
            ProjectEntity::getProjectLevel, query.getProjectLevel());
    wrapper.eq(StrUtil.isNotBlank(query.getStatus()),
            ProjectEntity::getStatus, query.getStatus());
    wrapper.orderByDesc(ProjectEntity::getSortOrder)
            .orderByDesc(ProjectEntity::getCreateTime);

    Page<ProjectEntity> page = this.page(new Page<>(query.getPageNum(), query.getPageSize()), wrapper);
    return PageResult.of(page.getTotal(),
            page.getRecords().stream().map(this::convertToVO).collect(Collectors.toList()));
}

这里的ProjectQuery是查询参数对象，ProjectVO是返回给前端的视图对象。为什么不直接返回ProjectEntity呢？比如cover_url存的是相对路径，你希望后端返回时拼接成完整路径，或者发布时间需要格式化成指定字符串，这些都可以在convertToVO这一步处理，而不是由前端各自处理。这个“实体不入参、不直接出参”的意识，也是答辩时拉开差距的加分点。

5.3 文件上传：路径、随机名和大小校验一个都不能少

非遗项目里有大量图片、视频资料需要上传，文件上传功能在毕设中基本是必做项。实现方案建议把上传文件保存到配置好的本地目录，比如项目的data/upload下，然后给前端返回一个资源相对路径。关键代码如下：

java复制@PostMapping("/upload")
public Result<String> upload(@RequestParam("file") MultipartFile file) {
    if (file == null || file.isEmpty()) {
        throw new BusinessException("上传文件不能为空");
    }
    String originalFilename = file.getOriginalFilename();
    String suffix = StrUtil.isBlank(originalFilename)
            ? "" : originalFilename.substring(originalFilename.lastIndexOf("."));
    if (!uploadAllowedSuffix.contains(suffix.toLowerCase())) {
        throw new BusinessException("不支持的文件类型");
    }

    String datePath = LocalDate.now().format(DateTimeFormatter.ofPattern("yyyyMMdd"));
    String fileName = UUID.randomUUID().toString().replace("-", "") + suffix;
    Path basePath = Paths.get(uploadDir).toAbsolutePath();
    Path targetPath = basePath.resolve(datePath).resolve(fileName);

    try {
        Files.createDirectories(targetPath.getParent());
        file.transferTo(targetPath.toFile());
    } catch (IOException e) {
        throw new BusinessException("文件上传失败");
    }

    return Result.success("/upload/" + datePath + "/" + fileName);
}

这里有几个实际开发中反复遇到的坑：

• 文件名一定不要使用用户上传的原始文件名，否则可能被多次重名覆盖、路径穿越甚至中文乱码，要用UUID或时间戳重命名。
• 图片不要转成Base64字符串存入数据库，数据库会迅速膨胀，响应接口会变慢，正确做法是存URL路径。
• 在application.yml里配置静态资源映射，将/upload/**映射到本地目录，否则前端访问不到上传后的图片。
• 上传目录不要放在src/main/resources下面，否则每次重新打包数据容易丢，而且本地目录也不应该参与打包。

5.4 登录认证方案：JWT加拦截器比Spring Security更顺手

管理系统一定会有后台登录权限验证。在这里我强烈推荐用JWT加一个HandlerInterceptor做轻量级认证，如果业务不复杂，完全不需要把Spring Security搬进来。

思路是：

1. 用户提交用户名密码，校验成功后生成token并返回给前端。
2. 前端将token放在请求头里，比如header的token字段。
3. 后端的拦截器对所有/admin/**请求做校验，token有效的放行，无效的返回401。
4. 根据解析出的用户ID和角色字段，再决定当前操作是否在权限内。

拦截器核心逻辑可以参考这段：

java复制public class AuthInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) {
        if ("OPTIONS".equalsIgnoreCase(request.getMethod())) {
            return true;
        }
        String token = request.getHeader("token");
        if (StrUtil.isBlank(token)) {
            throw new BusinessException(401, "未登录，请先登录系统");
        }
        LoginUser loginUser = JwtUtils.parseToken(token);
        if (loginUser == null) {
            throw new BusinessException(401, "登录状态已过期，请重新登录");
        }
        // 将当前登录用户保存到线程变量里，供后续Service使用
        UserContext.set(loginUser);
        return true;
    }
}

这套方案在毕设里属于“合理且能自圆其说”的级别，代码量不会失控。如果为了提升复杂度，可以把用户token同时存一份到Redis里，实现服务端主动下线，并在论文中写“采用Redis记录登录态，支持用户管理端强制退出”，技术上会更加完整。

5.5 审核状态推进：用枚举和Service方法，不上Flowable

经常有人问是不是需要Flowable工作流引擎来做申报审核流程。以非遗管理系统的毕设规模看，整个流程没有多分支会签，没有复杂的并行网关，单表状态流转就足够。引入Flowable至少要多维护一套流程定义，反而容易让系统过度复杂。

你可以把状态定义成代码枚举，比如DRAFT、PENDING、APPROVED、REJECTED、PUBLISHED，然后通过Service提供submitProject、approveProject、rejectProject三个方法，每个方法里校验当前状态是否允许继续流转，把状态变更和审核记录一起写入。这段业务逻辑虽然在技术上很简单，但是在答辩时最能展示你理解业务。

6. 部署演示和常见问题：系统能“跑起来”只是及格线

6.1 本地从零启动的完整步骤

本地运行的流程建议写成项目README，因为距离答辩时间越近，越容易忘记配置。启动步骤大致是这样：

第一步，新建数据库ich_db，执行项目里提供的init.sql脚本，把表和初始化数据建好。

第二步，打开application.yml，确认数据库账号密码改成自己本机环境。

第三步，启动Spring Boot主类，观察控制台没有报错。

第四步，如果项目是前后端分离，进入前端目录安装依赖并启动，比如npm install，然后npm run serve。

第五步，浏览器访问前端地址，使用初始化好的管理员账号登录后台。

第六步，随便新增一个非遗项目，上传一张图片，查看是否能正常显示。

能在几分钟内从零跑通环境，在答辩之前的准备阶段非常重要。很多源码本身是好的，但因为老师的电脑上MySQL版本不一致、JDK版本不同，现场启动失败的例子非常多。

6.2 运行阶段三个最常见的现场坑

第一个坑是数据库时区问题。MySQL连接串不写serverTimezone且MySQL为高版本时，启动后可能报时间区间异常或者连接被拒，解决办法已经在application.yml的url中加了serverTimezone=Asia/Shanghai