说起 Java 毕设选题，如果你不想再做那种满大街都是的图书管理系统、在线商城、博客论坛，同时又希望技术栈能撑得起“代码量足、业务完整、答辩有亮点”这三件事，那我建议你把“基于 Spring Boot 的非遗交流交易平台”或者“全国非物质文化遗产展示平台系统”这类题目好好研究一下。它不是一个简单的展示站，也不是普通的电商系统，而是把非遗展示、传承人交流、手工艺品交易三个场景揉在一起的综合平台，从用户端到管理端都有完整闭环。再加上这类题目自带文化属性，答辩时解释“为什么要做这个系统”会轻松很多。这篇文章就把选题拆解、表结构设计、功能实现顺序、调试过程中容易踩的坑、答辩话术和资料打包经验一次聊透。
1. 为什么非遗平台是“展示+交易+社区”三合一的好选题
1.1 非遗业务模型和普通电商系统的核心差异
大部分人把非遗交易平台理解成“商品上架 + 购物车 + 订单”，这其实低估了题目的业务复杂度。非遗商品的形态非常杂：有的是实体手工艺品，有的是线下课程体验，有的甚至是传承人上门定制服务。普通电商商品表用“标题、价格、库存”就能描述，但非遗项目还需要描述技艺流程、地域分布、传承人背景、文化故事。这些内容不是简单几个字符传就能存的，它要求系统具备较强的内容管理能力。
我做过的模拟项目里，一开始也照着商城设计表结构，结果做到一半发现非遗项目和商品根本不该混在一张表里。非遗项目是“内容资产”，商品是“交易资产”，两者可以用关联，但不能合并。这个认知直接影响后续所有模块的开发量。如果你能在需求分析阶段就意识到这一点，导师的印象分不会低。
另外，非遗平台通常还有一个“交流”需求，也就是用户之间讨论技艺、传承人发布动态、爱好者提问互动。这块业务既不是完全公开的贴吧，也不是私聊工具，而是带有平台审核性质的社区模块。把展示、交流、交易三个维度同时做好，题目才真正有了“系统”的味道。
1.2 从标题反推评委可能问到的十个问题
用一个题目之前，我会先站在评委角度把问题列出来，这是选题阶段最重要的一步。针对这个非遗平台，我建议你在写第一行代码前先能回答下面这些问题：
- 非遗项目和非遗商品到底是一对一还是一对多？
- 用户上传的非遗图片和视频用什么方式存储，路径规则怎么定？
- 传承人自己入驻算普通用户还是特殊角色，谁给他开权限？
- 交易订单如果涉及课程预约，履约状态怎么设计？
- 交流社区的发言是否需要先审后发？
- 检索能力是纯数据库模糊查询还是借助全文索引？
- 首页的热门推荐逻辑能不能给出一个朴素实现？
- 后台管理端需要哪些统计报表，比如用户数、商品数、订单量？
- 数据初始化脚本里应该放多少条非遗数据才能演示得动？
- 部署到服务器后图片上传路径为什么经常失效？
这些问题没有标准答案，但每一个都会在代码里体现出来。提前想清楚，后面做设计和写文档都会顺手很多。
1.3 为什么这个题适合作为 Spring Boot 毕设
从技术角度讲，非遗平台需要的知识点非常典型但不偏门。Spring Boot 做核心框架，MySQL 存业务数据，MyBatis-Plus 简化持久层，Spring Security 负责登录鉴权，前端可以用 Vue 或简单的 Thymeleaf。模块上有权限管理、文件上传、富文本、分页检索、订单事务、后台统计，几乎覆盖了企业开发里最常用的功能切片。难度上又比大型微服务低一个量级，不会出现一个人根本写不完的尴尬。
最关键的一点是，非遗平台给“扩展点”留了足够的想象空间。比如你可以把检索升级成 Elasticsearch 方案，可以把订单模块加一个简单的支付模拟，可以把首页推荐做成基于浏览记录的冷启动算法。这些扩展点不用全做，但每提一个，答辩就有了话题。
2. 技术栈选型与数据模型落地方案
2.1 一套省心又不掉价的组合
我在实际带项目时推荐过很多次这套组合：Spring Boot 2.7.x 或 3.x + MySQL 8.0 + MyBatis-Plus + Spring Security + Redis + Vue 2/3。Spring Boot 负责业务骨架，MyBatis-Plus 减少手写 SQL 的工作量，Spring Security 做 JWT 登录校验，Redis 可以承担验证码和热门数据的缓存。前端用 Vue 的话，前后端分离的结构在答辩时更好展示；如果前端不太熟，可以做成 Spring Boot + Thymeleaf 的服务端渲染，代码量少，逻辑也足够清楚。
选 MyBatis-Plus 而不是纯 MyBatis 的原因很现实：非遗模块的表关系虽然不复杂，但字段多，手写大量 resultMap 会浪费很多时间。MyBatis-Plus 的 LambdaQueryWrapper 可以让你在 Service 层少写不少样板代码。把 PageHelper 或 MP 自带的分页插件用起来，非遗列表、商品列表、评论列表都能快速实现分页。至于 Redis，小项目里最稳妥的用法是存短信验证码、登录 Token 黑名单和首页热点数据，不要为了用而用。
2.2 核心表结构：从非遗项目到交易订单的六个关键表
表设计是整个项目能不能顺利做下去的地基。我建议至少包含这样几张核心表：
- 非遗分类表：存放分类名称、父级分类，便于做多级导航。
- 非遗项目表：项目名称、项目编号、所属地区、非遗级别、项目简介、详细内容、封面图、传承人 ID、审核状态。
- 传承人表：姓名、简介、头像、所属机构或工作室、擅长技艺、入驻时间。
- 商品表：商品标题、商品类型、价格、库存、封面图、详情、关联非遗项目 ID、上架状态。
- 订单主表和订单明细表：订单编号、用户 ID、总金额、状态、收货信息；明细表记录商品 ID、商品名、单价、数量。
- 社区交流表：帖子标题、正文、图片、发布人 ID、所属非遗项目 ID、浏览数、回复数、是否置顶。
这里我特别说一下非遗项目和商品的关系。不要直接在非遗项目表里加商品 ID 字段，也不要让商品表直接存整个非遗详情。正确做法是商品表里有一个 heritage_id 外键，指向非遗项目表的 ID，这样语义清晰，查询时也可以用 join 或者分步查询拿到关联数据。别小看这个设计，很多同学把数据表做得像是“把 Excel 变成了 MySQL”，答辩时很吃亏。
下面给出一段简化的建表语句，你可以直接改成符合自己字段的版本：
CREATE TABLE heritage ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL COMMENT '非遗项目名称', category_id BIGINT COMMENT '非遗分类ID', region VARCHAR(100) COMMENT '所属地区', level VARCHAR(50) COMMENT '国家级/省级/市级', cover_url VARCHAR(255) COMMENT '封面图片', content TEXT COMMENT '项目详细介绍', inheritor_id BIGINT COMMENT '关联传承人ID', status TINYINT DEFAULT 1 COMMENT '0待审核 1已发布 2下架', view_count INT DEFAULT 0, create_time DATETIME ) COMMENT '非遗项目表';2.3 表关系设计上的三个关键取舍
第一，非遗项目和传承人是一对多，还是一个项目可以有多个传承人？实际业务中一个项目往往对应多个传承人，所以最好建一个中间关联表，而不是放一个 inheritor_id 字段。如果为了简化，非要放一个字段，那也要提前想好“主传承人”和“其他参与人”怎么处理，否则后期加功能很痛苦。
第二，交流帖和评论建议单独建表，不要复用统一的“留言表”。虽然统一表看起来省空间，但筛选逻辑会变得混乱，查帖子和查评论要拼不同的条件，代码可读性直线下降。
第三，订单状态建议用状态机思路，不要散落在代码里魔法数字乱飞。可以定义一个枚举类，比如 CREATED、PAID、SHIPPED、COMPLETED、CANCELLED。这样在 Service 层对订单状态做流转判断时，代码很清晰，答辩时也能讲出一点“工程规范”。
3. 从零到能答辩的功能实现顺序
3.1 第一周打通登录注册和后端骨架
很多同学一上来先做增删改查，结果数据库建了十几张表，项目启动后连登录都走不通。我建议第一周先把 Spring Boot 工程跑起来，完成用户注册登录、JWT 签发和校验、全局异常处理、跨域配置这四个基础能力。只有基础链路通了，后面的演示才能顺。
具体做法是：创建用户表，使用 BCrypt 加密密码，注册接口接收用户名和密码后写入数据库；登录接口校验成功生成 Token，前端后续请求在请求头中带 Authorization；后端用一个 JWT 过滤器读取 Token 并放入上下文。这里记得要求前端在 Axios 拦截器里统一注入 Token，否则登录态很容易丢失。
@PostMapping("/login") public Result login(@RequestBody LoginReq req) { User user = userService.login(req.getUsername(), req.getPassword()); String token = JwtUtil.generateToken(user.getId(), user.getRole()); return Result.ok().put("token", token).put("user", user); }第一周顺带把“全局异常处理”写好。很多同学的代码里每个 Controller 都自己 try-catch，样式很乱。用一个 @RestControllerAdvice 兜底处理参数异常和业务异常，后面所有模块的代码都能简化不少。
3.2 第二周完成非遗展示和检索模块
第二周开始做核心内容模块。非遗项目要支持分类查询、关键词搜索、详情页展示、热门浏览排序。推荐你做一个“非遗名录”页面，左侧放分类，右侧放卡片列表，点击进入详情。详情页展示项目介绍、传承人信息、相关商品和相关交流帖。
检索时最朴素的方案是用 MyBatis-Plus 的 like 条件拼接，但要注意当用户搜索词为空时不要拼上模糊条件。如果你想让代码稍微加分一点，可以给 name 和 region 字段做一个组合条件，比如“北京 剪纸”两个关键词都要参与过滤。这个细节不难，但很能体现考虑问题的周全程度。
这一步里还要考虑图片上传，建议统一封装一个上传接口，支持图片格式校验，上传后返回可访问的 URL。文件不要直接存数据库，存服务器本地目录，把访问路径映射到静态资源。如果你还没有设计好图片上传，第二周必须补上，因为后面商品、社区、传承人模块全都要用图片。
3.3 第三周把交易闭环跑通
交易模块是很多同学最容易卡壳的地方，因为涉及用户下单、库存扣减、订单生成、支付模拟这几个环节。非遗平台交易要处理“实物商品”和“体验课程”两种场景，我的建议是先做实物商品，把课程预约当成一种特殊类型商品，通过预定时间字段扩展。
下单流程可以这样设计：用户选择商品数量，后端检查商品是否上架，检查库存是否充足，扣减库存并生成订单。这里最怕重复提交，所以最好引入“防重复提交”的幂等方案。最简单的办法是前端生成一个请求唯一编号，后端在 Redis 里用该编号作为 key，第一次请求时放入，后续重复请求直接拒绝。
订单支付如果接真实支付渠道太麻烦，毕设一般用“模拟支付”按钮替代。模拟支付接口只需要把订单状态从“待付款”改为“已付款”，最好再把支付时间记录下来。真正要关注的是事务问题：库存扣减和订单生成必须在同一个事务里，否则会出现库存少了但订单没建成的异常。
3.4 第四周做社区交流和后台审核
社区模块能让系统从“展示平台”升级成“交流平台”。核心功能是发布帖子、帖子回复、帖子分页列表。建议帖子关联一个非遗项目，用户在浏览非遗详情时可以看到相关讨论，增加产品逻辑上的合理性。
后台管理端要提供角色划分：普通用户、传承人、管理员。管理员负责审核非遗项目、管理商品分类、审核帖子。非遗项目的发布流程最好设计成“提交后进入待审核，管理员审核后显示到前台”，这个简单状态机既能体现业务严谨性，又能名正言顺地增加一个后台页面。
到这里，系统整体闭环已经完成：用户看非遗信息，看相关商品，下单购买，还能在交流区参与讨论；管理员在后台维护数据。这就是一个能走通演示流程的完整系统。
4. 调试中容易踩的坑：跨域、图片上传、并发和事务
4.1 跨域配置和鉴权失效同时出现时怎么查
前后端分离项目里最常见的报错是 “Access-Control-Allow-Origin”，原因通常是后端没有配置跨域。Spring Boot 里写一个配置类实现 WebMvcConfigurer，重写 addCorsMappings 即可。但要注意，如果同时引入 Spring Security，只写 MVC 跨域配置还不够，Security 的过滤链里也要允许 OPTIONS 请求通过。
我调试的时候遇到过一种更隐蔽的情况：接口单独访问是通的，前端请求却 401。排查到最后发现 JWT 过期时间太短，前端页面停留一会儿再操作就失效。解决办法是把 Token 过期时间设置为两小时以上，同时前端在收到 401 响应时统一跳转登录页，而不是弹出乱码错误。
4.2 图片上传很热闹，一显示就 404
图片上传成功但前端无法显示，这是非遗类平台最容易遇到的坑，因为项目中图片数量多、路径长。图片上传到本地磁盘后，Spring Boot 默认不会把你指定的目录当作静态资源去访问。需要做资源映射，比如把所有 /files/** 请求映射到上传目录。
@Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/files/**") .addResourceHandler("file:" + uploadDir); }还要注意 Windows 和 Linux 的路径分隔符不一样。你本机测试用的路径是 D:/upload，部署到服务器后如果还按原来的写法，自然访问不到。建议把上传根目录配置到 application.yml 里，启动时读取配置拼接，不写死。这个细节如果文档里能说明白，读者照着做基本不会出问题。
4.3 库存扣减用事务就够了吗
答案是不够。多用户同时下单时，事务只能保证同一条 SQL 执行过程中要么成功要么失败，但无法解决超卖。比如商品库存还剩 1 件，两个请求同时读到库存为 1，都判断为可购买，然后都执行库存减一，最终库存变成 -1。
毕设里最稳妥的简单做法是用数据库乐观锁：更新库存时加上条件 status 或者 stock > 0。
UPDATE goods SET stock = stock - 1 WHERE id = ? AND stock > 0如果更新影响行数为 1，说明扣减成功；影响行数为 0，说明库存不足，直接抛业务异常。这样就不需要引入分布式锁，又能在并发测试时站住脚。事务方面要记住一个原则：事务方法不能被同类内部调用，否则 Spring 的代理机制会失效。比如在 Service 里一个 public 方法调用另一个加了 @Transactional 的方法，如果走的是 this.xxx()，事务不生效。要用注入自己或者把调用拆到另一个 Service 里。
5. 答辩与论文：代码讲解的“三层话术”和图表安排
5.1 代码讲解怎么讲才有条理
答辩现场最怕的是照着代码一行行念。我建议走“一条请求链路”讲法：从用户点击查询非遗列表开始，讲 Controller 接收到请求，然后 Service 处理业务，再经过 Mapper 访问数据库，最后把结果返回到前端。一个完整的链路讲下来，比你零散讲十几个接口要有说服力得多。
讲代码时一定要突出两个点：一是登录用了 JWT，而不是把用户信息塞在 Session 里，说明你理解了前后端分离下的鉴权方式；二是订单模块的事务处理，说明你知道库存和订单要保持一致。这两点虽然目前已经不算什么高深技术，但在本科毕设层面属于“规范做法”，讲出来评委听着顺。
5.2 论文里的图和表怎么安排
论文不需要多，但要有层次。必放的四张图建议是：系统总体功能结构图、业务流程图、E-R 图、部署架构图。其中 E-R 图是重点，要把非遗项目、传承人、商品、订单、用户、帖子这些实体的关系画清楚。
表格方面，可以放角色权限表、核心接口表、数据库表清单。角色权限表把三种角色的权限列清楚，比如普通用户能浏览下单，传承人能发布项目和商品，管理员能审核和统计。核心接口表列几个主要接口，标注请求方式、地址、参数和返回结果即可。这些内容不用写得像产品规格书，但要让导师一眼看出你确实完成了项目。
5.3 面对“创新点”这个问题怎么回答
非遗平台本身不算技术型创新，所以别硬讲“独创了什么算法”。比较稳妥的回答思路是“技术组合与业务场景的匹配”：非遗内容审核需要先审后发，所以我设计了状态机；非遗商品形态特殊，所以我用商品类型字段区分实物和体验；用户希望看到传承人与作品关系，所以我做了关联展示。这些听起来不大，但每一个都能落到代码里，比空谈人工智能、大数据要实在得多。如果学有余力，可以加一个“用户浏览足迹统计推荐”的功能，用简单的规则推荐同地区或同分类的非遗项目，答辩时还能多讲两分钟。
6. 整理“附源码、MySQL、文档、调试+代码讲解”这套资源时的实操经验
6.1 源码结构和注释怎么备才像样
很多同学最后打包代码时，把一堆编译后的 target 目录、IDE 配置文件和测试图片全都塞进压缩包，体验很差。整理源码前先把项目根目录清理一遍，保留 src、sql、docs、readme.md 这些主要目录。src 里可以保留后端和前端两个子目录，Spring Boot 后端按 controller、service、mapper、entity、config、common 分层放，Vue 前端按 api、router、views、components 放。这样别人拿到压缩包后打开目录结构，基本不用解释就能看懂。
注释不要求每行都写，但关键方法上要有中文注释，尤其像登录逻辑、下单事务、上传接口、状态流转这类地方。做不到每句解释，至少写清“这个方法是干什么的、为什么这么干”。代码讲解如果没有注释支撑，视频讲解也会卡住。
6.2 数据库脚本要做到可以直接跑
提供的 MySQL 脚本里最好包含建表语句、初始化和演示数据。初始化数据别搞太多，但一定要有：国家级非遗项目若干条、对应的传承人、几个商品、几个帖子、一个管理员账号、两个普通用户账号。我一般会在脚本末尾写上测试账号和密码说明，比如 admin / 123456，这样调试的时候省去很多沟通成本。
还有一个容易被忽略的坑：字符集。数据库连接串和建表语句要统一使用 utf8mb4，否则文化类文本里容易出现无法输入的生僻字或特殊符号。如果演示非遗项目名称里有繁体字或异体字，字符集不对会直接乱码。
6.3 调试视频的录制节奏和“全套”服务感
如果你打算把项目整理成“附全套服务”的资源包，调试演示视频不要录成两个小时的代码直播。录三到五分钟的重点演示更实用：启动后端和前端，打开首页展示非遗列表，登录用户，查看详情，下单，模拟支付，进入后台审核。把关键操作顺序录清楚，别人拿到后照着操作几分钟就能复现。
“全套资源”里最容易被忽略的是文档说明记得写清楚运行环境要求。Java 版本、MySQL 版本、Node 版本这些不写明白，对方环境不一致就跑不起来。问题排查部分可以把端口被占用、数据库连接失败、依赖下载缓慢这类情况提前预置答案，后续答疑会省力很多。
最后再分享一点个人经验：做这类带文化主题的系统，不要只盯技术。非遗的项目名称、地区、传承人关系这些“内容数据”如果做得细致，系统立刻显得有真实感，而不是干巴巴的测试数据。我自己每次搭这种项目，都会花半小时去整理一批规范的初始化数据，它们带来的整体观感提升往往比多写一个接口更明显。希望这篇东西能帮你把选题和实现想清楚，顺利拿下一个漂亮的作品。
