1. 项目概览：这个毕设到底在做什么
先说结论：这个题目的本质，是做一个面向东阳木雕非遗的“展示 + 交流 + 交易”三位一体网站，技术栈锁定 Java + SpringBoot。它不只是一个普通的信息展示站，而是要同时解决三个层面的问题：让外界能“看见”东阳木雕、让爱好者能“聊起来”、让手艺人能“卖出去”。对应到功能上，就是前端展示平台、文化交流社区、在线交易商城，再加上一个后台管理端。
选这个题做毕设有个天然优势：非遗数字化是国家政策支持的大方向，论文里“研究意义”那一段很好写，不需要编造。同时，这个题目不是一个纯粹的“增删改查”管理系统，它带有文化传播的属性，在答辩时能讲出特色。更关键的是，它拆开来看又足够接地气——用户注册、商品展示、购物车下单、论坛发帖评论，这些都是 SpringBoot 最经典的应用场景，技术难度不会失控，适合本科毕设。
从技术分工来看，这个项目的核心脉络是：SpringBoot 负责后端接口和业务逻辑，MyBatis（或 MyBatis-Plus）负责数据持久化，前端可以用 Vue + Element UI 做后台管理，用户端可以用 Thymeleaf 模板引擎直接渲染，也可以前后端分离。图片存储用本地文件或 OSS，搜索用 MySQL 模糊查询起步，后续可以接 Elasticsearch 做升级。这套组合是 Java 毕设最稳的选型，不花哨，但每一块都能讲清楚原理。
2. 技术选型解析：为什么 SpringBoot 是这个题目的最优解
2.1 SpringBoot 到底解决了什么问题
如果你是一个正在选型的毕设学生，首先要想清楚：为什么不用 SSM（Spring + SpringMVC + MyBatis）手搭项目？为什么不用更重型的 Spring Cloud？答案其实很直接——SpringBoot 的价值不在于它“能做什么”，而在于它“让你少做什么”。
SSM 时代的痛点，写过的人都知道：光配置文件就有 web.xml、spring-mvc.xml、spring-dao.xml、mybatis-config.xml，还要处理各种 jar 包版本冲突。一套配置搞一天，业务一行没写。SpringBoot 把这些全干掉了，通过自动配置和起步依赖，把“约定大于配置”贯彻到底。你建一个项目，选上 Web、MyBatis、MySQL 依赖，application.yml 里写上数据库连接信息，直接就能跑起来。
但对毕设来说，SpringBoot 还有一个更实在的好处：内嵌 Tomcat。老项目要额外装 Tomcat、把 war 包丢进 webapps，而 SpringBoot 直接java -jar就能运行。答辩现场演示的时候，不需要现场部署服务器，一个命令就把项目拉起来了，这个体验差距非常大。
另外要注意，SpringBoot 的自动配置不是“黑魔法”。我建议在论文里专门补一节“SpringBoot 自动配置原理”，讲清楚@SpringBootApplication这个组合注解如何通过@EnableAutoConfiguration加载META-INF/spring.factories（新版本是AutoConfiguration.imports）中的配置类。这一节写好了，答辩时老师问“SpringBoot 为什么能自动配置”你就能答得上来，光这一条印象分就上去了。
2.2 Java 生态下的配套选型怎么定
确定 SpringBoot 之后，剩下的选型思路应该是“够用、好讲、不出错”。
持久层框架：推荐 MyBatis-Plus。理由很现实：单表 CRUD 代码量少了一大半，内置分页插件，还有代码生成器可以直接把实体类、Mapper、Service、Controller 一次性生成。如果你是做毕设，时间本来就紧，MyBatis-Plus 能帮你把重复劳动压缩到最低。但论文里要写清楚它和原生 MyBatis 的关系——MyBatis-Plus 是基于 MyBatis 的增强工具，不做改变原框架的改动，只是为了简化开发。
前端方案：这里有一个关键分岔。如果你擅长 Vue，就用前后端分离：Vue 3 + Element Plus 做管理端，用户端可以用 Vue 或服务端渲染；如果你主要精力要花在后端，我建议用户端用 Thymeleaf，管理端用 Vue + Element UI 分离开发。原因很简单：毕设的核心评价指标是“你完成了一个完整的系统”，不是“你的架构有多新”。混合模式既保留了 Thymeleaf 在简单页面上的快速开发优势，又能体现你掌握前后端分离能力，一举两得。
数据库：MySQL 8.x 是标配。推荐用 navicat 或 DataGrip 做可视化操作，表结构设计省力不少。另外要注意 MySQL 8 的驱动配置和 5.x 不一样，com.mysql.cj.jdbc.Driver要写全，时区参数serverTimezone=Asia/Shanghai要加上，这个坑每年不知道绊倒多少人。
3. 数据库设计：非遗项目的数据模型怎么建
3.1 核心表的规划思路
东阳木雕非遗网站的业务链条是“游客浏览 → 用户注册 → 互动交流 → 下单购买 → 后台管理”，所以数据表的设计要围绕这条链来展开。我建议至少建 11 张表，按照模块分组：
用户域：用户表（user）、角色表（role）、用户角色关联表（user_role）。
内容域：木雕分类表（category）、木雕作品表（work）、非遗传承人表（artisan）、资讯文章表（article）。
交易域：购物车表（cart）、订单表（orders）、订单明细表（order_item）。
互动域：社区帖子表（post）、评论表（comment）、点赞表（like_record）。
这里我想重点说几个容易被忽略的设计细节。
第一，分类表不要只有两级。东阳木雕的实际分类很立体：按题材分有山水、花鸟、人物；按品类分有摆件、挂屏、佛像；按技法分有深浮雕、浅浮雕、镂空雕。如果你只做一张 category 表，用自关联的 parent_id 字段来实现树形结构，后面做“分类筛选 + 技法筛选 + 题材筛选”时就会非常痛苦。我建议把分类设计成多维度字段，直接在作品表里用category_type（题材）、category_craft（技法）、category_product（品类）三个字段来标记，查询时用 OR 匹配或全文索引，实现起来简单得多，而且前端筛选交互也直观。
第二，传承人表和作品表的关系是“一对多”，但作品表和传承人表之外，还要考虑“合作模式”的扩展。有的作品是某个传承人独立创作，有的是工作室集体作品，有的是已故大师作品由后人代售。所以传承人表里可以加一个status字段（活跃/不活跃），作品表里加一个is_authentic字段（是否真品认证），作为交易平台的信任背书。
第三，订单表一定要预留状态机。非遗木雕有很强的定制属性——很多买家是先看图再下单定制，不是买标准品。所以订单状态不能只有“待付款、已付款、已发货、已完成、已取消”，还要加“定制中（in_custom）”，联通到“定制需求表”。如果你不定制表，至少设计一个order_remark字段存备注，不然答辩时老师问“定制业务怎么处理”你就被动了。
3.2 表字段设计的实战细节
以木雕作品表（work）为例，标准字段设计如下：
id：主键，自增。artisan_id：传承人外键。title：作品名称。subtitle：副标题，用于首页展示的一句话简介。cover_image：封面图 URL。detail_images：详情图，可以用 JSON 数组存储多个图片 URL。description：作品描述（富文本）。story：作品背后的故事，这个字段是文化传播的关键，很多非遗网站做不好就是因为只有图片没有故事。material：材质，如樟木、椴木、柚木。craft：技法，如深浮雕、镂空雕。size：尺寸信息，如“45cm × 30cm × 15cm”。weight：重量。price：价格，Decimal(10,2)。stock：库存。status：上下架状态（0下架/1上架）。view_count：浏览量。is_hot：是否推荐首页热点。create_time、update_time：时间戳。
这里我要特别强调两个字段：story和view_count。story是“文化属性”的集中体现，一篇好的木雕故事可以写几百字，前端展示时放在作品详情页的“匠心传承”板块。view_count则不要只做数字累加，配合定时任务做每日清零或热度排行，可以支撑“热门木雕排行榜”功能——这个功能在答辩演示时非常出效果，一张图就展示了 Redis 缓存 + 定时任务 + 排行榜算法的能力。
订单表的核心字段是：order_no（订单号，建议用时间戳+随机数生成，唯一索引）、user_id、total_price、status（0待付款/1定制中/2已付款/3已发货/4已完成/5已取消）、consignee（收货人）、phone、address、remark（定制备注）、create_time、pay_time、ship_time。
社区帖子表建议加type字段区分帖子类型：0 是鉴赏交流、1 是求购定制、2 是工艺科普，这样社区展示页可以按 tab 切换，内容更丰富。
4. 核心功能实现：展示、交流、交易三线并进
4.1 展示模块：非遗之美如何用代码呈现
展示模块是这个网站的脸面，但很多毕设项目把展示模块做成了“图片列表 + 详情页”，这远远不够。东阳木雕是视觉审美极强的工艺品，展示模块的核心目标是“让用户隔着屏幕感受到木雕的质感”，代码层面的实现重点有三块：
第一，图片处理策略。木雕作品和普通商品不一样，用户需要看细节——刀痕、纹理、层次。所以每件作品的上传图片不能只传一张，我建议上传时一次性处理出五张：原图（大图）、封面图（720px 尺寸，做列表展示）、缩略图（300px，做推荐位）、详情大图（1920px 宽，看细节用的横版大图）、手机端适配图（414px 宽）。在 SpringBoot 里可以写一个ImageProcessUtil，基于 Thumbnailator 库实现比例压缩和裁剪，这个库稳定性好，一行代码能搞定图片缩放、旋转、水印。注意：图片裁剪要根据比例参数做 center crop，不然焦点偏了会把木雕美感裁没。
第二，分类导航与多维筛选。首页顶部要做成“分类导航条 + 作品瀑布流”结构。点分类可以从“题材”维度和“技法”维度同时筛选。后端的筛选接口用 MyBatis-Plus 的 LambdaQueryWrapper 构建动态条件，注意and和or的括号逻辑：题材和技法同时筛选时是且的关系，不同技法之间是或的关系，这个逻辑错了列表就错乱。
第三，文化展示不只是作品本身。我建议在首页留一个“传承人风采”板块，展示传承人的照片 + 简介 + 代表作品数量 + 故事视频链接。这里可以接一个简单的视频上传接口（存本地或 OSS），播放器用 HTML5 原生 video 标签就够。答辩时放一段木雕制作过程视频，演示效果远好于干巴巴的文字介绍。
4.2 交易模块：从购物车到订单的完整链路
交易模块是硬骨头，但也是毕业设计的加分项。我建议做“购物车 → 确认订单 → 在线支付 → 后台发货”的完整闭环，支付可以用沙箱模式接入支付宝，也可以用模拟支付。
购物车表结构很简单：id、user_id、work_id、quantity、selected（是否选中结算）、create_time。购物车接口四个就够：加入购物车、修改数量、删除、查询列表。注意加入购物车时要判断库存，不然前端下单了后端扣库存失败，会出现超卖问题。
订单生成流程要写清楚事务边界，这是答辩必问的点。流程是：前端提交订单请求（传递 workId 列表 + 收货信息）→ 后端开启事务 → 逐一查询作品库存并锁定（用SELECT ... FOR UPDATE）→ 计算出总价 → 生成订单主表和订单明细表 → 扣减库存 → 清空购物车对应商品 → 提交事务。中途任何一个环节报错，整体回滚，保证数据一致性。SpringBoot 里用@Transactional注解，默认回滚 RuntimeException，要记得设置rollbackFor = Exception.class，把检查异常也回滚，这个细节能直接在答辩时讲一遍。
支付这块，如果你真的想接支付宝沙箱，要注意：支付宝开放平台的沙箱环境是独立的一套账号体系，APP_ID、密钥、网关地址都和平时的商户配置不同，用 SDK 的时候要把AlipayConfig里的网关地址换成https://openapi.alipaydev.com/gateway.do，不然调不通。回调接口用@PostMapping("/notify")，验签逻辑一定要写——只校验sign和app_id，同时判断trade_status是TRADE_SUCCESS才更新订单状态，防止伪造回调。如果时间紧张，做一个“模拟支付”页就行，一键点击模拟付款成功后跳转到订单成功页，流程逻辑完全一致，但要知道和真实支付的区别，论文里说明清楚。
4.3 交流模块：社区功能的轻量实现
非遗社区不要做得太重，“轻论坛”的形态就够。核心功能是三个：发帖、评论、点赞。
发帖的富文本编辑器推荐直接集成 wangEditor 或 Editor.md。这里有一个容易踩坑的点：普通表单提交富文本时，内容会被进行 HTML 编码，提交到后端存数据库时没问题，但前端渲染回来会显示一堆转义符。正确做法是：前端提交时用JSON.stringify序列化，后端接收一个String content字段，直接存原样 Markdown 或 HTML；前端展示时再通过v-html渲染（Vue）或 Thymeleaf 的th:utext渲染。安全上要注意 XSS 过滤，SpringBoot 项目里可以写一个XssFilter对输入内容做转义，社区功能尤其必要。
评论模块建议做成两级评论：主评论 + 子回复，用parent_id自关联实现。一次接口返回所有该帖的主评论和子回复，前端递归渲染。注意显示层要做“展开/收起”，不然评论多的时候页面太长。
点赞模块用 Redis 缓存更优雅：点赞时SADD集合记录用户点赞，取消时SREM，定时任务每 5 分钟把集合大小同步到 MySQL。展示时直接查 Redis 的SCARD得到点赞数，性能好且挡得住频繁点击。如果不想引入 Redis，就用 MySQL 的like_record表 + 计数缓存字段，简单也能用。
4.4 后台管理模块：让系统“可维护”的关键
后台管理模块决定你的毕设是“demo”还是“系统”。我建议至少包含这些功能：
- 作品管理：新增/编辑/上下架/审核作品，上传作品轮播图。
- 传承人管理：维护传承人资料，支持自定义排序。
- 订单管理：查看订单详情、发货、标记完成，可按订单状态筛选。
- 用户管理：查看用户列表，禁用/启用账号。
- 社区管理：删除违规帖子、举报处理、置顶帖。
- 资讯管理：发布非遗相关文章，如展览公告、传承人专访。
后台安全上，用 Spring Security 做登录鉴权（这里注意：如果你只用简单的拦截器判断session里有没有 user，论文里要写清楚你的“轻量级权限控制方案”，不能说没做安全设计）。管理员账号建议第一次启动项目时用一个CommandLineRunner自动初始化，不然演示的时候没有管理员账号就很尴尬。
权限控制要控制到“角色”级：管理员能进后台，普通用户只能访问前台。接口层面用拦截器校验请求路径前缀（/admin/**必须登录且角色是 admin）就够，不用做细粒度的权限。
5. 实用工具与开发效率技巧
5.1 代码生成器：把重复工作压缩到极致
毕设项目的表结构定了之后，80% 的 CRUD 其实都可以通过代码生成器来生成。MyBatis-Plus 提供了一个 Generator 工具类，配置好数据源、表名、包名，一键生成实体类、Mapper 接口、ServiceImpl、Controller。生成完之后，你只需要补充业务逻辑和特殊查询，比如订单相关的多表联查、统计报表，自己手写。
这里我提醒一个点：代码生成器生成的 Controller 默认是/work这样的路径，如果你做前后端分离，接口路径建议统一加/api前缀，方便前后端联调时分清接口归属。同时统一返回Result对象（code、message、data），前端根据 code 判断成功失败，而不是靠 HTTP 状态码。
5.2 热部署与调试效率
SpringBoot 项目开发时强烈建议引入spring-boot-devtools依赖，改完代码自动重启，省去手动重启的时间。但要注意：devtools 默认的自动重启会触发所有 classpath 变化，如果你乱改配置也会触发，导致启动失败。解决方法是排除不必要的触发路径：spring.devtools.restart.exclude=static/**,public/**。
接口调试推荐直接用 IDEA 自带的 HTTP Client 或装一个 RestfulToolkit 插件，不需要动不动就打开 Postman。调试 SQL 时，在 application.yml 里开启 SQL 日志：
mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl这样每条 SQL 都会打印到控制台，SQL 写错了当场就能看到。这个配置调试完记得删掉或改成 slf4j，不然生产环境日志太乱。
5.3 文件上传与静态资源映射
上传木雕图片，SpringBoot 的 MultipartFile 接口用法很直观：
@PostMapping("/upload") public Result upload(@RequestParam("file") MultipartFile file) { String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String fileName = UUID.randomUUID().toString().replace("-", "") + ext; String uploadPath = System.getProperty("user.dir") + "/upload/" + fileName; File dest = new File(uploadPath); if (!dest.getParentFile().exists()) { dest.getParentFile().mkdirs(); } file.transferTo(dest); return Result.ok("/upload/" + fileName); }注意两个坑：第一，file.transferTo(dest)之前要确保父目录存在，不然会报FileNotFoundException。第二，从 Linux 上部署保存路径不能用写死的/home/user/upload，要用相对路径或从配置文件读取，方便在不同环境间迁移。静态资源映射要配置拦截upload/**指向本地文件目录：
@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:" + System.getProperty("user.dir") + "/upload/"); } }6. 常见问题与排查技巧实录
6.1 SpringBoot 版本太高导致的启动失败
做毕设时最怕的坑之一：在 start.spring.io 上生成项目时选了最新的 SpringBoot 3.x，然后引入老教程里的依赖，各种 jar 包不兼容。SpringBoot 3.0 之后javax.*包迁移到了jakarta.*，如果你用 2.x 的教程代码，import javax.servlet.http.HttpServletRequest会直接报错。这个问题的本质是 Java EE 改名，但答辩时很容易被老师追问。
我的建议：毕设老老实实用 SpringBoot 2.7.x 稳定版，对应 Java 8，教程最多、坑最少。如果你的学校对技术栈有“用新不用旧”的要求，再用 SpringBoot 3.x + Java 17，但所有包都要对应新版本，MyBatis-Plus 要用适配 3.x 的 3.5.3+ 版本，Druid 要用 1.2.16+。
排查启动失败的通用思路：先把mvn spring-boot:run改成mvn -X spring-boot:run，看详细日志；再检查 pom.xml 中所有依赖版本是否冲突。不要上来就百度“SpringBoot 启动报错”，先瞄准日志中的第一条 Exception——后面的报错大概率都是连锁反应。
6.2 前端页面 404 与跨域问题
前后端分离项目最经典的报错就是：前端请求/api/work/list，控制台报 404 或跨域。404 的排查方向是：Controller 里的@RequestMapping路径是否写对、是否加了/api前缀。跨域的解决方案在 SpringBoot 里写一个配置类：
@Configuration public class CorsConfig { @Bean public CorsWebFilter corsWebFilter(){ CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsWebFilter(source); } }如果你用的是 SpringBoot 2.x 的 MVC 体系，对应的类是CorsConfigurationSource+CorsFilter，注意区分。另外，如果你用 Nginx 做了反向代理，跨域也可以在前端用 Nginx 配置add_header Access-Control-Allow-Origin *来解决，不一定非得在后端写 CORS。
6.3 图片上传后无法显示
上传成功但图片 URL 打不开，十有八九是静态资源映射的问题。排查技巧：先看上传的文件是否真的落盘了，再访问http://localhost:8080/upload/xxx.jpg是否 404，如果是 404，检查addResourceHandlers配置是否正确，以及file:后拼接的路径是否与实际的保存路径一致。
还有一个隐蔽问题：如果你把文件保存到了项目根目录下的upload文件夹，但用 IDE 启动时当前工作目录可能是模块目录而不是父目录，System.getProperty("user.dir")的值会不一样。建议用配置类注入保存路径，避免不同环境下的路径漂移。
6.4 数据库连接相关的高频问题
Unknown database 'xxx'：数据库名创建了吗？注意 MySQL 在 Linux 下数据库名大小写敏感，Windows 下不敏感，这种差异会导致本地正常部署到服务器就报错。Public Key Retrieval is not allowed：MySQL 8 在 JDBC 连接时，如果驱动版本较新，需要加allowPublicKeyRetrieval=true参数，否则连不上。Communications link failure：大概率是防火墙没放行 3306 端口，或者是你的服务器 MySQL 配置了 bind-address，只允许本机访问。部署到云服务器之前先把这两项检查了。
6.5 答辩演示时的“保命”建议
最后分享一个我在实际答辩中总结的经验：做完项目后，一定要在“干净环境”下重新跑一遍。干净环境指的是：换一台没装过你项目的电脑（或者虚拟机），从拉代码、配 MySQL、执行 SQL 脚本，到启动 SpringBoot、打开前端页面，从头走一遍流程。每年都有学生本地跑得好好的，答辩现场因为缺依赖、数据库没初始化、端口占用而当场翻车——这锅不该技术背，是流程没验证。
另外，演示数据要提前造好：至少放 6 个分类、20 件作品、5 位传承人、10 篇帖子、20 条评论，别只塞一条数据让老师看到空荡荡的页面。数据填充得丰富，演示效果会提升一整个档次。
7. 个人实操心得与扩展方向
做这类非遗数字化项目，我最大的体会是：技术上它不复杂，真正的功夫在于“业务内容”怎么填充。东阳木雕是有真实文化底蕴的题材，你在做作品数据初始化时，可以花点时间查一查真实的东阳木雕历史——陆光正大师的《锦绣中华》、黄杨木雕和樟木雕的材质差异、深浮雕和透空雕的技法区别——把这些真实素材用进去，你的平台内容才有可信度。
技术扩展方向上，这个项目后续还可以做不少事情：比如给作品加上 3D/VR 展示，用 three.js 在网页上展示木雕模型的细节纹理；比如引入 AI 图像识别，让用户拍照识别木雕题材和雕刻技法；比如做推荐系统，根据用户的浏览历史推送相似风格的作品。这些方向可以作为论文的“未来展望”章节，也可以在答辩时作为后续工作介绍，但要记住自己在毕业设计的时间范围内完成了什么，别把架子铺太大。
最后再分享一个小技巧：部署到云服务器之后，配置一个免费的 HTTPS 证书（比如 acme.sh 自动申请），然后把网站链接晒到朋友圈或班级群里，让同学帮你测一下。别人通过公网访问到你做的非遗文化网站，那个成就感会一扫你写数据库时所有的疲惫。
这个项目的核心价值在于：它给了非遗一个数字化的窗口，让你用代码参与文化传承。做的时候用心一点，把一张木雕图、一段历史故事、一个手工作坊的故事放进系统里，这就不再只是个“毕设作业”了。
