做非遗数字化方向的项目，最容易踩的坑不是技术难度，而是“把题目理解成做个静态展示页”。我前阵子梳理过一个典型课题：基于SpringBoot的川剧文化遗产传承系统。它表面上是一个包含源码、报告和讲解视频的课程设计/毕业设计性质的项目，但真正值得展开聊的，是这个题目背后“如何把川剧的内容资产变成一套可维护、可检索、可运营的数字档案系统”的完整思路。这篇文章就按一个实际项目的完成过程来复盘：从需求拆解、数据库设计、后端实现，到前端呈现、部署避坑，最后聊几句可以继续延伸的方向。希望能给正在做同类文化类系统的同学提供一个能直接参考的样本。
1. 川剧数字化到底难在哪，SpringBoot又能解决什么
1.1 川剧传承面临的三个现实痛点
川剧和其他戏曲类非遗一样，资料形态非常多样：剧目有人物、行当、唱腔、身段、脸谱；脸谱本身又有颜色含义、勾画方式、对应的角色性格；加上剧照、音频、视频片段，散落在图书、老照片、线下展馆和各种零散网页里。想做传承，第一件事就是把“信息碎片”变成“结构化数据”。
第二个痛点是展示形态太静态。很多传统文化网站停留在“图文公告栏”阶段，用户进去只能看，不能搜，不能收藏，更谈不上按剧目、按行当去做关联浏览。传承不是单向输出，它需要让用户能自主地找到内容、反复回看，最好还能产生互动行为。
第三个痛点是内容维护过于依赖技术人员。如果每次更新一个剧目简介、换一张脸谱图都要改代码，那这个系统大概率上线即死亡。真正可用的文化传承平台，必须让运营人员通过后台直接维护内容。
这三件事集中到同一个系统里，就变成一个典型的内容管理系统：前台做文化展示与检索，后台做内容维护与统计分析。这种系统对技术栈的要求并不高，但对工程结构的清晰度、代码的可读性、后续扩展的便利度有要求。
1.2 SpringBoot在文化类项目里到底扮演什么角色
SpringBoot不是为非遗项目单独设计的，它提供的是Java Web开发里最成熟的“底座”：Spring MVC处理接口请求，Thymeleaf或模板引擎负责页面渲染，MyBatis/MyBatis-Plus操作数据库，拦截器做登录校验，文件上传机制管理图片和视频资源。这一套组合，放到川剧文化传承系统里，恰好能覆盖前面说的全部需求。
另外还有一个很现实的原因：这类题目普遍需要写万字报告，技术路线必须能在论文里讲清楚原理。SpringBoot的自动配置原理、拦截器机制、MyBatis的SQL映射，都是报告里能展开讲、答辩时能站得住的内容。相比前后端分离后到处是“黑盒”的方式，这种单体内聚的结构更容易让一个学生把每个请求的完整链路讲明白。
1.3 技术选型时做过什么比较
我见过不少人在这个题目上纠结“要不要上Vue前后端分离”。这里直接说结论：如果项目重点是文化内容展示和管理后台，而不是高并发复杂交互，SpringBoot + Thymeleaf + MyBatis-Plus的轻量单体方案是性价比最高的。
| 技术路线 | 适合场景 | 优势 | 需要注意的问题 |
|---|---|---|---|
| SpringBoot + Thymeleaf + MyBatis-Plus | 内容展示、后台管理型系统 | 开发快、部署简单、答辩好讲 | 前后端耦合，复杂交互受限 |
| SpringBoot + Vue前后端分离 | 交互复杂的平台型系统 | 前后端解耦、适合分工 | 需要处理跨域、Token鉴权、打包部署，工作量明显增加 |
| 传统SSM框架 | 教学要求必须用SSM的课程 | 结构经典 | XML配置多，开发节奏慢 |
| Node.js Express + MySQL | 简单原型验证 | 上手快 | 与Java课程的报告方向不一致 |
从“传承系统”这个定位看，内容以图文、视频展示为主，用户在页面上需要的是浏览、搜索、收藏、播放，后台需要的是对档案资料的增删改查。Vue能给视觉上加分，但也会把开发重心从业务逻辑挪到工程配置上。我在前面提到的版本里最终就选了SpringBoot单体方案，后续所有功能都围绕这个底座展开。
2. 从题目到需求清单：这个川剧传承系统最终要做什么
2.1 用户端功能明细
用户端不是“一个网页”，而是一条文化浏览链路。首页负责氛围引导，栏目页负责分类展现，详情页负责深度阅读，个人中心负责沉淀用户行为。具体拆下来大概是这样：
- 首页轮播图：展示重点剧目、重点活动和最新加入的档案资料。
- 分类导航：按川剧的传统行当或内容类型划分，比如生、旦、净、末、丑，以及剧目、脸谱、资讯。
- 剧目浏览与检索：支持按名称关键字搜索、按分类筛选，列表分页展示。
- 剧目详情：包含剧情简介、主要人物、行当分类、剧照图片，以及在线视频播放。播放器用HTML5的video标签即可。
- 脸谱画廊：脸谱图片以卡片墙展示，点击进入详情后能看到脸谱名称、所属角色、颜色涵义、勾画特点。
- 文化资讯公告：非遗活动通知、川剧相关知识文章，支撑日常内容更新。
- 用户收藏：登录用户可以对喜欢的剧目或脸谱进行收藏，在个人中心统一查看。
- 轮播推荐位：运营可以控制的推荐数据，而不是写死在页面里。
这里有一个产品层面的细节：不要把传统行当只当“分类标签”用，它其实是最好的浏览维度。一个对川剧不太了解的人，点击“净”这个分类时如果能直接看到对应的脸谱和代表剧目，比单纯搜索更容易建立认知。
2.2 管理端功能明细
管理端是整个系统的“内容生产线”，所有用户端能看到的文化资源，都由后台维护。功能模块包括：
- 管理员登录：账号密码校验，登录成功后进入后台会话。
- 剧目管理：新增、编辑、删除剧目；上传封面图片和视频文件；设置推荐位；控制上下架状态。
- 脸谱管理：维护脸谱名称、图片、角色、颜色涵义、详情描述。
- 资讯动态管理：发布和编辑文化资讯。
- 分类管理：维护前台展示的文化分类，比如行当分类、内容类型分类。
- 轮播管理：上传轮播图片，配置跳转链接和排序。
- 数据概览页：展示剧目数、脸谱数、用户数、资讯数等统计信息，用图表直观呈现。
管理端设计上有一个容易被忽略的点：所有信息列表都要带查询条件。比如剧目管理页，管理员要能通过名称、分类、状态筛选列表，不然内容多了以后找一条历史记录会非常费劲。
2.3 非功能性需求怎么取舍
非功能需求不是答辩用的套话，而是直接影响系统能不能跑起来的约束：
第一是安全。密码不能明文存数据库，至少要用MD5加盐或BCrypt做散列；列表查询必须用参数占位防止SQL注入；上传接口要限制文件类型和大小，不能允许随便上传可执行文件。
第二是性能。文化类项目数据量不大，但分页查询是必须的，不能一次性把所有剧目查出来塞给前端。视频文件建议统一使用压缩后的MP4格式，H.264编码，避免原始素材体积过大导致页面卡顿。
第三是兼容性。前台页面要用响应式布局，至少在手机浏览器上能正常浏览和播放视频，毕竟文化内容的主要传播场景在移动端。
第四是可维护性。后台操作日志是可选的，但如果时间充裕，建议加一张简单日志表，记录谁在什么时候改了什么内容，这个细节在报告里会显得很完整。
3. 数据库设计：用表结构把川剧档案真正装起来
3.1 核心实体及业务关系
数据库设计是这个项目最值得花时间的地方，因为后续所有功能都建立在表结构上。核心实体包括用户表、分类表、剧目表、脸谱表、资讯表、轮播表、收藏表。
实体关系的理解方式是这样的：用户和剧目是多对多关系，通过收藏表关联；分类和剧目是一对多关系，一个分类下可以有多个剧目；剧目和图片/视频，主要通过字段直接存储路径的方式解决，不单独建资源表。整库的表规模控制在七八张左右，既满足需求，又不会把系统复杂度抬得太高。
我见过有的项目把视频和图片拆成“资源表”，然后通过资源ID去关联业务表。这个做法在素材平台型系统里是对的，但在一个课程设计规模的传承系统中会过度设计——查询一个剧目详情要关联两张表，上传流程也更绕。直接在一个剧目记录里保存封面路径和视频路径，反而干净直接。
3.2 核心表结构详解
剧目表是内容管理的核心表，字段设计如下：
CREATE TABLE drama ( id BIGINT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(100) NOT NULL COMMENT '剧目名称', category_id BIGINT NOT NULL COMMENT '所属分类', lead_role VARCHAR(50) DEFAULT NULL COMMENT '主要行当/角色', introduction TEXT COMMENT '剧目简介', cover_image VARCHAR(255) DEFAULT NULL COMMENT '封面图路径', video_url VARCHAR(255) DEFAULT NULL COMMENT '视频路径', view_count INT DEFAULT 0 COMMENT '浏览量', sort_order INT DEFAULT 0 COMMENT '排序权重', status TINYINT DEFAULT 1 COMMENT '1上架 0下架', is_deleted TINYINT DEFAULT 0 COMMENT '软删除标记', create_time DATETIME DEFAULT CURRENT_TIMESTAMP, update_time DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ) COMMENT '川剧剧目档案表';这里有几个字段需要认真考虑：
- is_deleted软删除标记：管理员删错剧目时能在后台恢复，这是内容管理系统的保命设计。
- status上下架状态：新录入的资料可以先设置为下架，审校之后再上架，避免浏览者看到未完成的内容。
- sort_order排序权重：文化项目里“编辑推荐”是个高频需求，用数字排序字段比按时间排序更灵活。
- video_url和cover_image只存相对路径：不要存完整的http地址，因为开发环境和生产环境的域名不一样，存相对路径后统一由后端返回完整访问地址。
脸谱表的结构类似，但要额外保存颜色涵义和角色特质：
CREATE TABLE face_painting ( id BIGINT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100) NOT NULL COMMENT '脸谱名称', opera_role VARCHAR(50) DEFAULT NULL COMMENT '对应角色', color_type VARCHAR(50) DEFAULT NULL COMMENT '主色调', color_meaning VARCHAR(255) DEFAULT NULL COMMENT '颜色涵义', description TEXT COMMENT '脸谱介绍', image_url VARCHAR(255) DEFAULT NULL, status TINYINT DEFAULT 1 ) COMMENT '川剧脸谱档案表';收藏表在设计时要注意唯一约束，防止同一用户对同一内容重复收藏：
CREATE TABLE favorite ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id BIGINT NOT NULL, drama_id BIGINT DEFAULT NULL, face_id BIGINT DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_user_drama (user_id, drama_id), UNIQUE KEY uk_user_face (user_id, face_id) ) COMMENT '用户收藏表';3.3 建表时容易被忽略的细节
第一，字符集要明确指定。中文内容存储最稳妥的是utf8mb4，不是utf8。MySQL的utf8是不完整的，遇到生僻字或者特殊符号有可能会乱码，而川剧资料里恰恰容易出现历史剧目名和繁体字。
第二，索引不全等于性能没问题。列表页经常按category_id和status查询，这两列应该建联合索引；搜索如果依赖title模糊查询，数据量小的时候直接LIKE就可以，不需要强行上全文索引。
第三，外键约束我建议不要建。逻辑关联就够了，用代码保证数据一致性。课程设计里一旦建了物理外键，删除数据时各种关联报错会让调试变得很麻烦，报表导出、后期扩展都会受限。
第四，时间字段统一用DATETIME，不要用字符串。很多人嫌麻烦直接存String，但后期要做时间排序、统计数据时就后悔了。
4. SpringBoot后端核心实现：文件上传、分页查询、权限校验
4.1 项目初始化与依赖清单
后端工程结构按标准分层拆包：controller、service、mapper、entity、config、common。控制层只做参数接收和结果封装，业务逻辑放在service，数据库操作走mapper，实体内定义字段映射。
pom.xml里需要引入的核心依赖如下：
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-thymeleaf</artifactId> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3</version> </dependency> <dependency> <groupId>com.mysql</groupId> <artifactId>mysql-connector-j</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>commons-io</groupId> <artifactId>commons-io</artifactId> <version>2.11.0</version> </dependency>如果是Spring Boot 3.x，JDK版本必须用17或更高；如果是Spring Boot 2.7.x，JDK8或JDK11都可以。这个版本匹配问题后面专门说，它是很多人一上来就跑不起来的第一道坎。
4.2 上传接口的实现与静态资源映射
图片上传是内容管理系统的核心操作。实现思路是：客户端通过表单提交文件，后端校验格式和大小，然后保存到服务器磁盘指定目录，返回可访问的相对路径。
@RestController @RequestMapping("/admin/file") public class FileUploadController { @Value("${upload.path}") private String uploadPath; @Value("${upload.access-path}") private String accessPath; @PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.error("请选择文件"); } String originalName = file.getOriginalFilename(); String ext = StringUtils.getFilenameExtension(originalName); Set<String> allowed = Set.of("jpg", "jpeg", "png", "gif", "mp4"); if (!allowed.contains(ext.toLowerCase())) { return Result.error("不支持的文件类型"); } if (file.getSize() > 200 * 1024 * 1024) { return Result.error("文件不能超过200MB"); } String newName = UUID.randomUUID().toString().replace("-", "") + "." + ext; File dest = new File(uploadPath, newName); try { file.transferTo(dest); } catch (IOException e) { return Result.error("保存失败"); } return Result.success(accessPath + "/" + newName); } }上传路径必须放在配置文件里，而不是写死在代码中：
upload: path: D:/sichuan-opera/upload access-path: /upload关键问题是静态资源映射。浏览器访问/upload/xxx.jpg时，SpringBoot默认不知道这个路径对应磁盘的哪个目录，需要写一个配置类：
@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Value("${upload.path}") private String uploadPath; @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + uploadPath + "/"); } }这个映射配置是无数人卡住的地方：文件明明传上去了，但页面图片不显示，90%的原因是addResourceLocations里的路径漏了file:前缀或者末尾少加了斜杠。Windows下还要注意反斜杠问题，最好统一用正斜杠。
4.3 分页与条件检索的落地
列表页的分页使用MyBatis-Plus的分页插件实现，配置一个拦截器即可：
@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }剧目列表查询的Service层代码相对直观：
public PageResult<Drama> pageDramas(int pageNum, int pageSize, String keyword, Long categoryId) { Page<Drama> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Drama> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Drama::getStatus, 1); wrapper.eq(Drama::getIsDeleted, 0); if (StringUtils.hasText(keyword)) { wrapper.like(Drama::getTitle, keyword); } if (categoryId != null) { wrapper.eq(Drama::getCategoryId, categoryId); } wrapper.orderByDesc(Drama::getSortOrder).orderByDesc(Drama::getCreateTime); dramaMapper.selectPage(page, wrapper); return new PageResult<>(page.getRecords(), page.getTotal()); }这里要注意：如果项目用了软删除标记，所有查询条件都要带上is_deleted = 0，不然删除的内容还会出现在列表里。也可以用MyBatis-Plus的逻辑删除注解@TableLogic，但字段名和全局配置必须统一，否则容易出现在写条件时漏掉的情况。
4.4 登录与拦截器的权限控制
管理端的权限控制，我强烈建议用Session加拦截器，不要一上来就上JWT。理由很简单：这是一个后台管理系统，不是开放API平台，Session方案代码量少、好理解、答辩时也能讲得清楚。
登录逻辑是：用户名密码匹配后，把管理员信息放进Session。拦截器统一拦截/admin/**路径，除登录接口外都检查Session：
@Component public class AdminInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object admin = request.getSession().getAttribute("admin"); if (admin == null) { String ajaxFlag = request.getHeader("X-Requested-With"); if ("XMLHttpRequest".equals(ajaxFlag)) { response.setStatus(401); } else { response.sendRedirect("/admin/login"); } return false; } return true; } }从实用角度看，Session还有个额外好处：服务端可以主动控制登录状态的有效期，不用在客户端琢磨Token过期后如何刷新。课程设计和大多数中小型内容系统，用Session完全够。
5. 前端展示层是怎么做出“文化感”的
5.1 页面渲染技术选型的取舍
前端的呈现方式直接决定用户对系统的第一印象。在这个项目里，我选择了Thymeleaf模板加Bootstrap响应式布局，而不是Vue单页应用。原因前面表里说过，这里再补充一点：传承系统需要被搜索引擎收录，需要首屏直接输出内容，服务端渲染天然更适合这类场景。
Thymeleaf处理动态数据的写法很直接：
<th:block th:each="drama : ${dramaList}"> <div class="card"> <img th:src="${drama.coverImage}" th:alt="${drama.title}"> <h3 th:text="${drama.title}"></h3> <p th:text="${drama.introduction}"></p> </div> </th:block>好处是服务端直接输出完整HTML，浏览器拿到什么就渲染什么，图片地址、视频地址都是渲染后的最终结果，不用额外请求接口拼数据。
5.2 首页和档案详情页的信息组织
首页的信息动线是：轮播图吸引注意力，分类导航降低选择门槛，推荐剧目建立内容深度，脸谱画廊形成视觉记忆点，最新资讯补充动态感。轮播数据来自后台配置，推荐剧目来自sort_order字段排序，脸谱画廊从脸谱表里取8到12条数据，以图片墙形式展示。
剧目详情页是内容深度的集中体现。顶部是剧名和基本信息，左侧放封面图，右侧放行当、主演、所属分类等关键信息，下面是大段剧目简介，再往下是剧照和各段简介。视频区域用HTML5的video标签：
<video controls preload="metadata" width="100%" poster="封面图地址"> <source th:src="${drama.videoUrl}" type="video/mp4"> </video>另外详情页一定要做“相关推荐”。同一分类下的其他剧目，按浏览量或创建时间排列，既延长用户停留时间，也让系统形成浏览闭环。这个功能实现起来很简单，就是按categoryId查同分类数据，排除当前记录，取四条。
脸谱详情页要将“颜色涵义”突出展示。如果脸谱主色调是红色，页面里要有对应的语义解释。这类内容虽然只是一段文字，但在数据库里必须单独存字段，而不是拼进描述文本里——因为后期可能会用颜色做筛选，单独字段才能支撑这种查询。
5.3 后台数据看板的实现细节
后台数据概览页面不只是一个装饰页。它从剧目表、脸谱表、用户表、资讯表分别统计数量，再用一个轻量图表组件展示分类分布情况。
统计接口在Service层写几个count查询，比如SELECT category_id, COUNT(*) FROM drama WHERE is_deleted = 0 GROUP BY category_id，返回结果直接传给页面。图表用ECharts的CDN引入，在页面加载后用Ajax获取统计JSON，渲染柱状图或饼图。
这里有一个建议：统计页不要用动态查询拼SQL。保持简单查询返回List
6. 开发中的实测避坑记录与部署注意事项
6.1 SpringBoot版本与数据库连接不匹配
这套系统最常出现的第一个报错，是启动时连接MySQL失败。原因通常不是密码错误，而是MySQL连接驱动版本或时区参数问题。
如果是MySQL 8.x，JDBC连接串必须显式加时区参数：
spring: datasource: url: jdbc:mysql://localhost:3306/opera?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false同时驱动依赖要用com.mysql.cj.jdbc.Driver，这个类从MySQL 8开始才是标准驱动。如果项目里还写着旧版本的com.mysql.jdbc.Driver，启动时会直接抛ClassNotFoundException。
Spring Boot版本和JDK版本的对应关系也很容易踩：
| Spring Boot版本 | 要求JDK版本 | 常见问题 |
|---|---|---|
| 2.5.x | JDK8 | JDK17下启动报UnsupportedClassVersionError |
| 2.7.x | JDK8或11 | 相对稳定 |
| 3.0.x+ | JDK17 | 配置和旧教程差异较多，很多第三方starter版本需要升 |
我的建议是直接使用Spring Boot 2.7.x加JDK8或JDK11的组合，教程最多、兼容性问题最少，足以支持这个系统。
6.2 图片上传后前端无法回显
“上传成功但图片裂开”是我见过频率最高的运行期Bug。排查链路按顺序走：先在浏览器直接访问接口返回的图片URL，如果404，检查静态资源映射是否生效，确认file:前缀有没有写；如果URL能访问但页面图片还是裂的，十有八九是数据库里存了完整http://localhost:8080/upload/xxx.jpg，而部署环境换了端口，访问地址自然失效。
解决方案就是前面说的：数据库只存相对路径/upload/xxx.jpg，页面渲染时由模板引擎保留这个相对地址，浏览器自己拼当前域名访问。这样换域名、换端口都不会出问题。
还有一个小坑是Windows本地的文件路径分隔符。File.separator在Windows下是反斜杠，而SpringBoot的资源映射更习惯正斜杠，混用时会出现图片路径中带\导致访问失败。处理办法是保存路径时统一用File.separator生成磁盘路径，但返回给浏览器的路径永远拼正斜杠。
6.3 分页插件与多表查询的坑
MyBatis-Plus分页插件在写简单单表查询时非常好用，但一旦在多表关联查询中使用，count统计就会出现重复行数问题。
我见过一个案例：剧目表和收藏表关联后，分页count统计出的总数比实际剧目数多，原因就是JOIN导致结果集膨胀。解决方案有两种：
一是保持主查询单表，另外再用一个service方法查收藏数，把数据组装到返回对象里；二是把复杂JOIN查询拆成两次查询，先查主列表ID集合，再查关联数据组装。这两种方案都避开了“单条SQL硬拉关联数据分页”的坑，代码可读性也好。
6.4 部署到服务器后的资源路径问题
本地开发时，很多人习惯把上传目录放在项目源码的src/main/resources/upload/下。开发没问题，但打包成jar部署时就会出大事：jar包重新发布后，上一版上传的图片和视频全部丢失，或者写入的临时目录在重启后被清空。
正确做法是在配置文件中指定独立的上传目录，比如Linux服务器上的/data/opera/upload/，或者jar包同级的./upload/目录。同时在部署命令里提前创建目录，保证目录存在并具备写权限。
mkdir -p /data/opera/upload nohup java -jar opera-system.jar --spring.config.location=classpath:/,file:/data/opera/application.yml > /data/opera/logs/run.log 2>&1 &另外注意multipart文件大小限制。SpringBoot默认单文件上传上限是1MB，不改配置的话，上传稍微大一点的视频就会报MaxUploadSizeExceededException。要在配置里设置：
spring: servlet: multipart: max-file-size: 200MB max-request-size: 200MB7. 个人体会与可继续深挖的方向
7.1 复盘后我觉得这个系统最值钱的部分
如果只追求做成一个“作业”，这个系统一个星期就能赶出来。但真正让它在答辩和二次开发中站得住脚的，不是代码写了多少，而是“内容结构化的设计思路”：剧目、脸谱、颜色涵义、行当分类都被设计成了可查询、可关联的字段，而不是一段无法操作的纯文本。
哪怕只做了一张脸谱表，只要它把脸谱名称、角色、颜色、涵义拆成了独立字段，这个表就已经具备“档案”的基本形态，后续无论是做数据可视化、做知识图谱还是做小程序端，都能直接用。相反，如果所有内容都塞进一个content字段，那系统做得再花哨，也只是一堆图片的堆砌。
7.2 后续可以加入的扩展功能
这个项目做稳定以后，有几个方向值得继续扩展：
一是全文检索。当剧目和脸谱资料量增长到几千条以后，MySQL的LIKE模糊查询体验会明显下降，可以引入Elasticsearch做索引。但这个扩展必须等数据积累到一定规模再做，资料只有两三百条时硬上ES属于过度设计。
二是视频处理。上传的音视频如果能用FFmpeg做统一转码、自动压缩、加水印，系统的专业度会提升一个等级。主要作用是解决视频格式兼容性问题，以及防止文化资源被轻易盗用。
三是互动和二次创作功能。比如用户留言评论、用户上传自己的脸谱绘制作品，这能让“传承”从浏览变成参与。前端加个图床逻辑，后端沿用现有上传接口，每天调用量不大，整体成本可控。
7.3 给同类文化数字化项目的一句建议
我个人的实操体会是：做这类系统，一定要“后台先行，字段先行”。先把后台内容维护流程跑通，再考虑前台视觉；先把每个内容类型的数据字段定义清楚，再动手写页面。顺序一旦反了，大概率会出现“页面做完了，发现后台录入时少了一个关键字段”这种返工情况。
另外，最后再分享一个容易在答辩时被问到的小细节：为什么选择SpringBoot而不是其他框架。对这个系统来说，答案不是因为SpringBoot是“新技术”，而是因为它能通过自动配置和成熟的生态，把内容管理的通用复杂度压到最低，让我们能把更多精力放在川剧文化资料本身的结构化整理上。这个回答比“大家都在用所以我用”要更有说服力——这大概也是这套项目真正值得拿去参考的原因。
