基于SpringBoot的川剧非遗数字化传承系统开发实战解析

做了几个非遗数字化方向的项目之后，再看到“基于SpringBoot 川剧文化遗产的传承设计与实现”这个标题，第一反应是：这不是一个随便换皮的管理系统，而是一套真正需要吃透业务、还要兼顾内容呈现、权限控制、数据归档和作品交付的完整课题。SpringBoot只是底座，核心价值在于“传承设计”这四个字——怎么把川剧的历史、剧目、脸谱、名家、资讯这些分散内容，组织成一个有逻辑、可维护、能演示的数字化平台。这篇文章我会从实际开发的角度，把这个项目的选题逻辑、功能拆解、数据库设计、关键代码实现、部署运行到答辩整理全流程讲清楚，给正在做类似系统或打算用非遗题材做课设/毕设的朋友一份可以直接参考的实操笔记。

1. 项目先盘清楚：川剧传承数字化平台到底解决什么问题

拿到这个标题，我第一件事不是开IDE写代码，而是先把业务场景和用户角色理顺。川剧作为国家级非物质文化遗产，目前面临的核心问题其实很典型：受众老龄化、年轻观众对剧种不了解、优质内容缺乏线上展示渠道、剧种资料散落在各种线下文献和视频里，缺少一个集中式的数字化窗口。

从这个角度理解，“传承设计”不只是一个功能堆砌，而是用互联网产品的方式去重构川剧的传播链条。系统首先要解决“让不了解的人看得懂”的问题，所以前台需要有清晰的内容分类和图文展示，比如川剧历史、表演特技（变脸、吐火等）、经典剧目、脸谱艺术；其次要解决“让感兴趣的人找得到”的问题，所以要有检索、分类、收藏和资讯更新能力；最终要能支撑“让想管理的人管得住”，这就是后台的内容发布、用户管理、评论审核。

这个系统的目标用户可以分成三层：普通访客（文化爱好者、普通观众）、内容运营者（管理员/文化单位工作人员）、系统维护者（开发运维人员）。在设计功能时，这三层需求要同时满足。还有一个很实际的问题——这类项目通常会用来做课程设计或毕业设计，所以交付物不只是能跑的代码，还要有配套的万字开发报告和讲解演示。也就是说，代码层面的模块划分是否清晰，直接决定后续写文档和答辩时顺不顺手。

我用下来最明显的一个感受是：非遗类系统比普通CRUD项目多的部分，是对“内容模型”的精细设计。你不能把所有展示内容都塞进一张“文章表”，因为脸谱、剧目、名家、资讯的数据结构各不一样，强行用一个通用表会导致后期扩展和维护都很痛苦，这是我建议动手前先花一天时间把ER图和数据字典敲定的原因。

2. 技术选型与系统架构：为什么SpringBoot在这里是合适的底座

2.1 技术栈选型背后的逻辑

做这类项目，技术选型不是越新越好，而是“稳、熟、够用”。我最终确定的方案是：SpringBoot 2.x（2.7.x，稳定而且教程多）作后端基础框架，MyBatis-Plus做数据持久层（不用写太多XML，内置分页和条件构造器能省大量重复工作），MySQL 8.0存储数据，前端服务端渲染用Thymeleaf搭配Bootstrap 4，图表展示用ECharts，额外引入Redis做首页热点数据的缓存（这个可以视工作量裁掉，不是必须）。这套组合也是国内Java Web课程设计和毕业设计最主流的配置，遇到问题容易查资料，答辩时也说得清。

对比一下几种常见方案，你就能理解为什么这么选：

如果选前后端分离，开发会更灵活，但意味着要额外写接口文档、处理跨域、做Token鉴权，对于课时有限的项目会拉长周期。Thymeleaf把数据和页面模板绑在一起，一套SpringBoot跑完，演示起来也更直观——开一个应用，浏览器访问就是完整页面。

2.2 分层架构设计：模块边界划到哪里才不难受

我习惯把项目按经典的三层架构划分，再在Controller和Service中间加一层清晰的实体流转：

• Controller层：接收请求、做参数校验、返回视图或JSON。不做业务逻辑，只做“路由转发”。
• Service层：承载业务规则，比如发布剧目时要同步更新分类统计、删除文化条目时要清理关联的收藏和评论。
• Mapper层：操作数据库，尽量用MyBatis-Plus自带方法，复杂查询才写XML。这一点非常重要，因为团队协作或者自己后期维护时，SQL散落在XML里比散落在业务代码里更容易排查。
• Entity/DTO/Query层：数据库实体、前端接收的参数对象、查询条件对象分离。很多同学喜欢直接用Entity接收前端参数，刚开始省事，后面字段一多就乱了。我建议为了少踩坑，至少把查询条件和实体分开。

模块拆分上，按照业务域划分包结构。前后台功能使用统一的后端应用，通过路径前缀和登录状态区分访问权限，前台页面路径是/front/**，后台管理是/admin/**。这样做的好处是：共享一个登录态、一套拦截器、同一套Service，不需要维护两个启动工程。

目录结构大致是（用Maven单工程，简洁且符合大多数课设代码习惯）：

src/main/java/com/xxx/culture ├── config // 配置类：Redis、上传路径、拦截器、MyBatisPlus分页 ├── controller // 前台Controller + 后台Controller（按模块分） ├── service // 接口 + 实现类 ├── mapper // MyBatis-Plus Mapper接口 ├── entity // 数据库实体 ├── dto // 前端入参对象、统计VO ├── common // 统一返回结果、常量、自定义异常 ├── utils // 工具类：文件上传、MD5加密、JWT等 └── interceptor // 登录检查、Admin权限拦截

2.3 一个容易被小看的点：前后台共用一个登录体系

非遗类网站的前台用户和管理员，其实没有必要分成两张用户表。一张用户表，用role字段区分角色即可。前台注册的用户是普通角色，只能浏览、收藏、评论；管理员是后台手动预置的，登录后可以进入后台管理。权限校验用拦截器做：

• /admin/**路径：必须登录，且role=ADMIN，否则重定向到管理员登录页。
• 用户中心相关路径：必须登录，否则提示“请先登录”。
• 静态资源和前台公开页面：直接放行，不用拦截。

这样做大大简化了代码量，你在报告里也方便描述“基于角色的访问控制”这个点，面试官或导师都认这个方案。实际开发中我看到许多同学把用户表拆成user和admin两张表，然后登录又要写两套逻辑，完全没必要。

3. 数据库建模：核心表设计和“为什么这么建”的思路

3.1 数据模型总览

数据库是整个系统最值得投入时间设计的部分，表设计好，写代码的效率会质变。我按业务域拆出了下面这些核心表，并且把它们划分为“用户域”、“内容域”、“交互域”三类。

其中culture_article是内容域里信息量最大、最核心的表，因为它承担了“文化知识”和“资讯文章”的双重任务。我把这类内容表的设计思路展开一下。

3.2 内容表字段设计要点

以culture_article表为例，建表SQL核心思路如下：

CREATE TABLE `culture_article` ( `id` int NOT NULL AUTO_INCREMENT COMMENT '主键', `title` varchar(100) NOT NULL COMMENT '标题', `category` varchar(50) NOT NULL COMMENT '分类：history/skill/repertoire/artist/profile', `cover_image` varchar(255) DEFAULT NULL COMMENT '封面图URL', `summary` varchar(200) DEFAULT NULL COMMENT '摘要，列表页展示', `content` text COMMENT '详情正文（HTML格式）', `author` varchar(50) DEFAULT NULL COMMENT '发布人/作者', `view_count` int NOT NULL DEFAULT '0' COMMENT '浏览量', `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态：0下架 1上架', `create_time` datetime NOT NULL COMMENT '发布时间', `update_time` datetime DEFAULT NULL COMMENT '更新时间', PRIMARY KEY (`id`), KEY `idx_category` (`category`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='川剧文化内容表';

几个容易忽略的设计细节：

• category用字符串代码而不是纯数字type。因为代码可读性高，前端判断方便，比如category=face_pattern一目了然，不需要对着数字字典才能看懂。
• summary字段一定要留。列表页如果直接展示content大段文字，页面性能会变差，而且列表排版很难看。在Service层可以做一个简单处理：如果summary为空，就从content截取纯文本前80个字符。
• content用text类型，存的是前端富文本编辑器生成的HTML。这里提醒一个坑：富文本内容入库之前一定要做XSS过滤，至少要把<script>标签去掉或转义，否则上线后容易被脚本注入。我一般用Jsoup的clean方法处理一遍，几十行代码的事，能挡掉大半安全风险。
• view_count不要求实时高并发准确，简单累加就行。如果后续引入Redis，可以把这个字段做成异步更新或缓存更新，但现在不用过度设计。
• 所有表统一utf8mb4字符集，因为要支持特殊表情符号和生僻字；排序规则用utf8mb4_general_ci即可，兼容性最好。

3.3 脸谱表和剧目表怎么建才能体现“专业”

脸谱是川剧视觉符号里最有辨识度的部分，建模时不要只做一个“图片+名称”的简单结构，至少带上角色行当、色彩主调、寓意说明这几类信息。

CREATE TABLE `face_pattern` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(50) NOT NULL COMMENT '脸谱名称/角色', `role_type` varchar(50) DEFAULT NULL COMMENT '行当：生旦净丑等', `color_tone` varchar(255) DEFAULT NULL COMMENT '主色调，多个用逗号分隔', `image_url` varchar(255) NOT NULL COMMENT '脸谱图片URL', `description` text COMMENT '寓意与角色介绍', `drama_name` varchar(100) DEFAULT NULL COMMENT '出自剧目', `create_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='脸谱资料表';

剧目表设计要注意：一个剧目可能有多个剧照，但表结构里不把图片字段设计成多值字段。我的做法是另建一张opera_image表，存opera_id和image_url，一对多关联。同样，剧目的“主图”也单独一个cover_image字段放主缩略图，其余图片放子表。这样列表页加载快，详情页再展示完整图集。

如果你不想额外建图集表，也可以用“逗号分隔URL”的字段存多图，但这不是规范做法，数据库范式上说不通，后面要扩展图片排序、图片标题时就麻烦了。既然这个项目后续是要写万字报告和答辩的，表设计规范化非常加分。

3.4 收藏表和评论表：交互功能的基础

用户收藏功能的核心是“唯一性约束”，同一用户对同一资源只能收藏一次：

CREATE TABLE `user_favorite` ( `id` int NOT NULL AUTO_INCREMENT, `user_id` int NOT NULL COMMENT '用户ID', `target_type` varchar(20) NOT NULL COMMENT '类型：article/opera/face', `target_id` int NOT NULL COMMENT '对应内容的ID', `create_time` datetime NOT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_target` (`user_id`, `target_type`, `target_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户收藏表';

评论表的核心是“关联范围”的区分，因为评论既可以发生在文化文章下面，也可以发生在剧目详情页下面。我用target_type字段区分评论对象是文章还是剧目，避免建两张评论表。针对管理员的后台评论审核，加一个status字段，0为待审核，1为通过，2为驳回（或者不显示即可）。

值得注意的：评论模块建议做“父评论和回复”的简单支持吗？我认为第一版没有必要做嵌套结构，只要做“一级评论列表+按时间倒序”就够了；项目周期不允许把评论系统做成社区论坛的复杂度。真要加，最多加一个parent_id字段支持单层回复，再深就过度设计了。

4. 核心功能实现：从演示效果出发，把代码落到实处

4.1 首页数据聚合：一个Controller如何组织多数据源

首页是系统门面，展示效果直接决定第一印象。我的首页设计思路是：轮播图（3-5张，突出川剧剧照、脸谱墙等视觉元素）+ 热门文化内容（按浏览量排序取6条）+ 经典剧目推荐（维护一个is_recommend推荐标记字段，取8条）+ 最新资讯。首页的数据来自4-5张表，不要直接写在Controller里一把梭，建议通过Service层做一个聚合方法：

@GetMapping("/") public String index(Model model) { // 轮播图：bannerService.listActive() List<Banner> banners = bannerService.listActive(); // 文章模块：按分类取热门 List<CultureArticle> hotArticles = articleService.listHot(6); // 剧目推荐：固定取推荐位 List<OperaFestival> recommendOperas = operaService.listRecommend(8); // 最新资讯：取前5条 List<News> latestNews = newsService.listLatest(5); // 藏品数量统计等 model.addAttribute("banners", banners); model.addAttribute("hotArticles", hotArticles); model.addAttribute("recommendOperas", recommendOperas); model.addAttribute("latestNews", latestNews); return "front/index"; }

代理层不需要额外配置，只要Service之间方法粒度清晰，Controller的可读性就很高。前端页面用Thymeleaf循环输出，加上简单的片段复用（footer、header抽成~{front/common :: header}），页面维护体验很好。首页加载性能方面，由于数据量不大，第一次可以不加缓存，但尽量保证SQL是走索引的，避免全表扫描。

4.2 登录注册与MD5加盐：千万别用明文密码

登录注册模块看起来简单，但安全点是答辩常问的地方。密码一定不要明文存库，至少要MD5加盐。虽然MD5不算最安全，但对于课设项目来说，如果配合“固定盐值+多次摘要”已经能过基础审核。我建议直接用DigestUtils.md5DigestAsHex(password.getBytes())做一层摘要，再在用户表里加一个salt字段，每个用户随机生成盐，平时存的是salt + password的MD5值。

// 注册逻辑（简化） String salt = UUID.randomUUID().toString().replace("-", "").substring(0, 6); String encryptPwd = Md5Util.md5(salt + rawPassword); User user = new User(); user.setUsername(username); user.setPassword(encryptPwd); user.setSalt(salt); user.setRole("USER"); userService.save(user);

登录校验时，从库里取出这个用户的salt，再做一次salt+输入密码的MD5比较。即便数据库泄露，攻击者拿到的也只是密文和盐，不会立刻破解出原始密码。SSO登录不现实，本地系统自己维护即可。

使用Session还是JWT？从简洁角度，传统Session最容易被理解，也最好在报告中解释。SpringBoot默认就是HttpSession，配合拦截器判断登录状态很直接。如果你要前后端分离，那才需要考虑JWT；本项目用Thymeleaf服务端渲染，Session就够。

4.3 文件上传：脸谱图片和封面图的设计要领

上传功能是我在实际中踩过最多坑的一个点。本地文件存储虽然简单，但要注意几个配置：

spring.servlet.multipart.max-file-size=10MB spring.servlet.multipart.max-request-size=15MB

上传之后，把文件写到项目的upload/目录下，文件访问通过虚拟路径映射暴露。配置方式：

@Configuration public class UploadConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { // 上传文件访问路径：/upload/** 映射到本地磁盘目录 String uploadPath = System.getProperty("user.dir") + File.separator + "upload" + File.separator; registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath); } }

这一步必须在WebMvcConfigurer里配，不是在静态资源目录放个文件夹就行。否则本地在IDE里运行时有路径，一旦打成Jar包部署到服务器，上传文件的访问路径就会404。

另外，文件名一定要重新生成，不要用用户上传的原始文件名。原始文件名可能包含中文、特殊字符，可能存在路径穿越风险，直接用System.currentTimeMillis()或UUID.randomUUID()生成新文件名，后缀名从原始文件名中提取。这样做还有个附带好处：文件名称规整，部署到服务器上不会因为编码问题乱码。

4.4 后台管理：数据网格、搜索筛选和联动删除

后台管理功能最怕的就是“只做CRUD”，没有任何逻辑。我在设计后台时特意增加了几处能展示业务思考的功能点：

• 文章按分类筛选+关键字模糊搜索+分页展示。利用MyBatis-Plus的LambdaQueryWrapper动态拼接条件，非常简洁。
• 删除内容时做“联动清理”。删除一篇文章时，同时删除这篇文章关联的评论记录和收藏记录。这一步如果忘了，容易产生脏数据，写报告时也能作为优化点。

@Transactional(rollbackFor = Exception.class) public void deleteArticle(Integer id) { articleMapper.deleteById(id); commentService.removeByTarget("article", id); favoriteService.removeByTarget("article", id); }

• 用户管理。管理员可查看注册用户列表、禁用/启用账号。这里最简单的设计是在用户表加一个status字段（0禁用/1正常），被封禁用户登录时被拦截，提示联系方式。
• 数据可视化。后台首页做一个统计面板，用ECharts展示“各类内容数量柱状图”和“近30天内容发布量趋势折线图”。统计SQL用GROUP BY即可，不用太复杂。视觉上，一块统计页面立刻让系统体现出“管理平台”的感觉。

4.5 前台交互体验：收藏、评论、浏览量一个都不能少

前台页面的核心交互是三块：收藏、评论、浏览数。这几块都是服务端渲染下典型的“页面刷新后反馈”逻辑。

收藏按钮的状态判断：在列表页或详情页通过Thymeleaf判断favorited变量是否为空，为空则显示“收藏”，不为空则显示“已收藏”。切换逻辑放到一个Post请求接口，前端用一个小表单提交。

评论功能：详情页底部显示评论区，用户登录后才能发布。Controller直接接收表单字段，组装评论实体入库，设置status=0等待后台管理员审核。前台列表只查询status=1的评论。虽然这是最简单的审核流，但配合后台的评论审核列表，整个流程是闭环的，报告里也能讲得清。

浏览量：在文章详情接口里直接UPDATE一次view_count += 1，再把viewCount传到页面。不要用“先查出来+1再存回去”的操作，会有并发脏写风险，直接在SQL层原子累加最稳：

articleMapper.increaseViewCount(id); // UPDATE culture_article SET view_count = view_count + 1 WHERE id = ?

5. 部署运行：从本机到演示环境的完整落地

5.1 本地环境准备与初始化

在演示或开发前，把环境准备流程固定下来：安装JDK 8/11（根据SpringBoot版本定，2.7用JDK8即可）、Maven 3.6+、MySQL 8.0、Redis（如果使用）、IDEA或Spring Tool Suite。导入工程后，修改application.yml里的数据库连接信息：

spring: datasource: url: jdbc:mysql://localhost:3306/culture_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你自己的密码 driver-class-name: com.mysql.cj.jdbc.Driver

在src/main/resources/sql/下提供初始化SQL脚本：建库脚本、建表脚本、基础数据脚本。基础数据一定要预先准备几类内容，否则页面演示是空的，给人感觉项目没做完。项目自带源码包里通常已含这些资源和准备步骤说明，真实性对我们这类项目来说优先级很高。

5.2 打包与服务器运行

本地开发推荐mvn spring-boot:run或IDE直接运行Application主类。需要打包部署到服务器时，用Maven打Jar包：

mvn clean package -DskipTests java -jar target/culture-0.0.1-SNAPSHOT.jar

为了运行日志不刷屏，可以这样启动：

nohup java -jar target/culture-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod > app.log 2>&1 &

服务器上MySQL的初始化也要执行同一个SQL脚本，如果有外网访问需求，注意要在安全组里放行端口。静态上传目录要提前创建，权限设置为当前服务用户可写，否则图片上传时大概率报AccessDeniedException。

5.3 数据库初始化数据准备的技巧

准备初始化数据是一个很消耗时间但特别重要的工作。文化文章、剧目、脸谱、名家数据不用准备几百条，但只要每种内容有5-8条质量够高的数据即可支撑完整演示。内容来源可以整理公开资料（注意不要照抄大段版权内容），图片用影视剧官方剧照或博物馆公开图片资源，务必检查来源合规性。报告里写“数据来源为公开资料整理”是稳妥的。

我习惯把初始化数据做成一棵“可重复执行”的SQL：先TRUNCATE再INSERT，保证每次重新导入结果一致。

6. 部署中遇过的典型问题与排查实录

6.1 中文乱码：从URL到数据库全链路排查

实习那会儿第一次跑SpringBoot项目，页面中文全变成问号。后来总结出套路：页面编码问题看Thymeleaf模板，连接串里加characterEncoding=utf8；HTML头部加<meta charset="utf-8">；MySQL建库时指定utf8mb4。一般就是这三个位置的问题，通常是其中一个位置漏了。另外如果还乱，检查Tomcat的URIEncoding，在spring.datasource.url连接串中已经比较重要了。IDEA里如果配置文件出现中文乱码，注意文件编码要设置为UTF-8。

6.2 上传图片后访问404

这个前面提到过，是静态资源配置没生效。加上WebMvcConfigurer里映射/upload/**到磁盘路径后就好了。还有一点坑：如果用System.getProperty("user.dir")获取的是当前工作目录，用IDE启动时是工程根目录，用Jar运行时是执行java -jar的目录，最好在配置里指定一个绝对路径，比如把上传目录配置为/home/data/upload，可配置化，避免环境切换后路经变了。

6.3 登录拦截器放行资源不全

很多新手配置拦截器时只放行了/login和/css，结果页面没有任何样式。原因是Bootstrap、jQuery、图片这些静态资源也已经被拦截了。放行规则至少包含：

registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/admin/**", "/user/**") .excludePathPatterns("/login", "/doLogin", "/css/**", "/js/**", "/img/**", "/plugins/**", "/upload/**", "/front/**", "/error");

注意/front/**这些公开页面都需要放行，否则游客连首页都进不去。建议写完后打开浏览器开发者工具，看Network里被拦截的资源是什么状态码，快速定位问题。

6.4 分页插件配置失败导致分页无效

使用MyBatis-Plus分页，一定记得配置分页插件MybatisPlusInterceptor并添加PaginationInnerInterceptor。不配置的情况下，Page参数会被忽略，SQL里没有LIMIT，就变成了全量查询。很多教程没提这一句，所以实现分页后列表还是所有数据。检查点很简单，看控制台打印的SQL有没有LIMIT。

6.5 日期格式前后端显示不一致

默认的LocalDateTime序列化后可能是一个数组（LocalDateTime被Jackson序列化成类似[2024,1,1,10,30,0]的结构），页面显示肯定不对。在实体字段上加@JsonFormat注解，或者在application.yml里全局配置：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

对Thymeleaf服务端渲染则要记得在模板里使用#temporals.format(...)来格式化。这个坑在写日期展示功能时几乎必踩一次。

7. 关于源码、报告和讲解：交付时我是怎么整理的

这个项目的标题里明确带了“源码+万字报告+讲解”，说明最终交付形态不只是能运行的代码，还包括文档和口头表达。我这里分享下我整理这些交付物时的习惯，虽然不是全部代码内容，但思路都是通用的。

7.1 源码注释和包结构的“整洁度”直接影响成绩

写代码时顺手写注释是个好习惯，尤其是类和关键方法的注释。不用每行都写，但类头注释说明模块职责、方法头注释说明输入输出和业务规则，已经很加分。变量命名使用驼峰、接口命名统一就行。报告中的“系统设计”章节基本可以照着代码结构来写，逻辑一致才能减少写文档时的认知成本。

7.2 万字报告的大纲思路

我的报告结构一般是：绪论与选题背景 → 国内外研究现状（非遗数字化方向）→ 相关技术介绍（SpringBoot、MyBatis-Plus等）→ 系统分析（可行性分析、需求分析、用例图）→ 系统设计（总体架构、功能设计、数据库设计）→ 系统实现（分模块截图+核心代码说明）→ 系统测试（功能测试、性能测试、用例表）→ 总结与展望。这个结构也是大多数院校课程设计和毕业设计的标准结构，属于“安全但完整”的写法。

每一点都配上系统的实际截图和核心代码段落，报告自然就充实了。标题里说“万字”，说明深度要求不低，需要你在数据库设计、功能实现细节、测试用例上多写一些分析性文字，不要只是堆截图。

7.3 答辩讲解怎么讲才出彩

讲解演示时不要照着PPT念。我的思路是先花1分钟讲清痛点（川剧传承难、资料分散），再用业务流程图把系统功能串联，然后重点演示两个亮点：一是前台页面效果和文化内容展示，二是后台的CRUD、权限控制和数据可视化。这两块是导师或评委最关注的“完成度”证据。讲完功能后，留出时间讲一两个技术难点（拦截器权限、文件上传、分页优化）作为个人深入度体现。

如果能把这个项目中“用数字化手段做非遗传承”的社会意义带一句，结合演示效果才不显得突兀。这类文化主题项目，在答辩或者汇报里有一个文化立意，整体的印象分会高不少。

8. 这个项目做完之后，还可以怎么横向扩展

项目本身可以做很多扩展，按推荐优先级排列：加入全文检索功能（用Elasticsearch或MySQL的全文索引，支持对剧目、文章内容的模糊搜索），搜索体验会明显提升；加入Redis缓存首页热点数据和文章浏览数，提高性能；引入Vue做一个专题页面，比如“川剧脸谱在线变装互动”（融合互动游戏元素，演示非常出彩）；增加在线投票或预约看戏功能，贴近真实的文化单位业务场景；对接视频接口展示川剧经典片段，内容形态更丰富。每一条我都评估过工作量和对成果的提升幅度，其中Redis缓存和搜索是性价比最高的两个增强方向。

我在实际做同类项目时发现，评委或导师往往特别关心两个点：一是系统有没有“解决一个具体问题”，二是有没有“超出CRUD的亮点”。数字化展示、内容管理、角色权限这些属于基础分；推荐算法、数据可视化分析、互动功能这些属于加分项。如果你时间充裕，挑一个加分项做深，项目水平会再上一个台阶。

回到标题本身，川剧文化遗产传承系统这个选题，一方面文化立意比较正，另一方面技术体系完整、业务逻辑清晰，是一个非常标准且容易驾驭的SpringBoot全栈项目。把技术做好只是第一步，把技术讲成故事、把代码整理成体系、把项目成果准确传递出去，才是这类“源码+报告+讲解”交付模式的精髓。