每年到了毕设答辩季，选题群里总会出现两类人：一类拿着电商系统换个皮肤到处问行不行，另一类想找个"有文化含量又不太难实现"的题目。我自己的SpringBoot东阳非遗木雕文化交流网站，基本属于第二类。它从表面看很像"商城加内容管理"，但真正做完之后我发现，非遗数字化传承这个方向被严重低估了——它不是给老手艺套个网页壳子，而是要把展示、交易、交流、知识沉淀这些完全不同的业务揉进同一个平台里。

这篇内容我会把整个项目的定位、技术选型、数据库设计、核心模块实现、踩坑经历都写出来，尽量讲清楚每一步背后的理由。不管你是正在纠结毕设题目的计算机专业学生，还是想了解非遗类Web项目怎么做产品设计的同学，应该都能从里面找到可以直接参考的东西。

1. 从毕设选题到落地：非遗数字化平台的三层价值

1.1 为什么是"东阳木雕"而不是普通商城

选题阶段，指导老师给的方向是"文化类+互联网应用"。一开始我也想过做一个标准的信息管理系统，无非是用户管理、商品管理、订单管理三件套。但后来调研了一下东阳木雕的现状，发现这个方向如果认真做，比普通商城有深度得多。

东阳木雕以平面浮雕见长，材质多用樟木、椴木，题材从花鸟鱼虫到戏曲人物都有，工艺链条很长：选材、画稿、粗坯、修光、打磨、上漆，每一步都有讲究。但问题是，大众对它的认知基本停留在"红木家具上的花纹"，年轻人更不知道这门手艺背后的流程和故事。这种认知断层，恰好是数字化平台可以补上的东西。

所以我把平台的价值拆成三层：第一层是在线展示，让用户看清楚一件木雕作品的全貌和细部；第二层是文化交流，把传承人、工艺步骤、历史知识变成可浏览的内容；第三层才是交易，让喜欢的人能下单购买。三层缺一不可，只做交易就变成普通电商，只做展示又缺商业闭环。这个定位直接决定了后面的数据库设计和功能模块划分。

1.2 三类用户角色决定功能边界

项目一开始，我先把用户角色理清楚了。系统里不是只有"买家和卖家"这种电商二元结构，而是有游客、注册用户、传承人、管理员四类角色。

游客可以浏览作品、查看工艺展示、搜索知识库，但不可以下单和发帖；注册用户可以下单购买、在社区发帖评论；传承人比较特殊，他首先是注册用户，然后提交证明材料申请认证，认证通过后才能发布作品、更新工艺步骤；管理员负责审核传承人申请、审核作品上架、管理社区内容。这个角色划分比普通商城多了一层"认证"逻辑，也是最容易做乱的地方。我在后续设计里把传承人认证做成了一张单独的表，和用户表一对一关联，用审核状态字段控制整个流程。

1.3 文化内容不是"充数"的，它需要结构化

做非遗文化平台最容易犯的错，是把文化内容当成系统里的"通知公告"来维护，写几个静态页面就算展示过了。我自己的处理方式是，把文化内容拆成两种数据结构：一种是作品级工艺步骤，每个作品关联若干道工序图与文字说明；另一种是知识库文章，按题材、年代、技法分类。这样用户在浏览一件樟木雕挂屏时，不光能看到成品照片，还能看到"画稿—打坯—修光"的步骤图解，文化和商品真正长在了一起。

从实现角度说，正因为多了这批结构化内容，系统才不至于沦为一个"带壳电商"，答辩的时候也更有东西可以讲。这块我在第5节会展开说具体设计。

2. 技术选型的取舍：SpringBoot为主干的项目架构

2.1 后端技术栈：Spring Boot + MyBatis-Plus的组合

后端我选的是Spring Boot 2.7 + MyBatis-Plus + MySQL 8.0。理由很实际：Spring Boot本身社区资料多，遇到问题几乎都能搜到答案；MyBatis-Plus把单表CRUD简化到了极致，省下来的时间可以去做业务逻辑和前端。

有人会问为什么不用Spring Cloud或者微服务那一套。我的观点是，毕设项目最忌讳的就是为了技术而技术。非遗木雕平台的数据量、并发量都远没到需要拆服务的程度，单体应用加缓存完全够用，还省掉了服务注册、链路追踪这一堆运维工作。架构上的"克制"本身就是一种能力，答辩的时候老师问"你为什么不用微服务"，你回答"当前业务规模下单体更合适"，这比硬堆技术要好得多。

认证方案上我用的JWT加Spring Security。实话说Spring Security的学习曲线有点陡，但做毕设可以不用它做太复杂的权限模型，我主要用过滤器拦截接口，配合JWT的Token校验就能覆盖大部分场景。如果你时间紧，也可以用一个简单的拦截器实现登录校验，效果差不了太多。

2.2 前端方案：前后端分离还是模板引擎

前端我纠结过一段时间。最终方案是Vue 2 + Element UI做管理端，用户端用Vue做单页应用，后端只提供JSON接口。这样前后端彻底分离，调试的时候不需要依赖后端页面，开发体验舒服很多。

但这里有个诚实的提醒：如果你对Vue不熟，或者学校的毕设要求里没有明确写"前后端分离"，用Thymeleaf模板引擎也能做出很好看的网站。Thymeleaf的好处是前后端在一个工程里，部署简单、减少跨域配置，对新手更友好。我选Vue纯粹是因为之后工作大概率会用到，想借毕设练一下，并不是说模板引擎方案不行。

前后端分离带来的一个额外工作是跨域处理。我在后端写了一个全局CORS配置类，允许本地开发的前端端口访问接口，这个细节很多人会漏。下面是我用的配置：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/api/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .allowCredentials(true) .maxAge(3600); } }

2.3 文件存储方案：本地磁盘加静态映射

作品图片、头像、工艺步骤图这些文件往哪放，是一个比想象中更值得提前想清楚的问题。

我选择的是本地磁盘存储加Nginx静态映射：文件上传后保存到服务器的一个固定目录，比如/data/woodcarving/images/，然后通过Nginx把/images/路径映射到这个目录。这样做的好处是简单可控，不需要注册任何云服务，本地跑起来就能用，部署到服务器时改一下配置就行。

如果你所在的高校有提供对象存储服务，那当然可以用云存储，但没必要在毕设阶段强上。有一个坑必须先说：文件路径不要写死在代码里，最好放到配置文件里用@Value注入，否则你本地是Windows的D:\files，服务器是Linux的/data/files，一换环境就出事。这个坑我第6节会重点讲。

3. 数据库建模：非遗作品的实体关系与状态流转

3.1 用户、传承人、作品：三张核心表的关系

数据库设计是整个项目里最不能赶时间的部分。我画了不下五版ER图，最后沉淀出三张核心表：用户表、传承人表和作品表。

用户表字段不复杂：id、username、password、nickname、avatar、phone、role、status。role用整型表示，0是普通用户、1是传承人、2是管理员。传承人表是用户表的扩展，通过user_id和用户表一对一关联，字段包括真实姓名、个人简介、从艺年限、擅长技法、审核状态。为什么要单独拆一张表而不是直接加在用户表里？因为不是所有用户都有传承人身份，拆开之后，普通人相关的查询不会背上用不上的字段，后续加"传承人证书图片""代表作品数量"这些属性也很方便。

作品表是核心中的核心：id、artist_id、title、category_id、material、size_desc、craft_desc、price、stock、cover_url、status、view_count、sale_count。这里的status我用0、1、2、3分别代表草稿、待审核、已上架、已下架，每一步状态都有明确含义。作品表和传承人表通过artist_id关联，这样平台可以按"这个传承人有哪些作品"来查询，这是展示传承人主页的基础。

3.2 分类与标签：多对多关系解决检索问题

作品分类我用了标准的父子分类表：category表里有id、name、parent_id，可以支持两级分类，比如"挂屏类—花鸟挂屏""摆件类—人物摆件"。

光有分类还不行，木雕作品有很多交叉属性，比如"材质是樟木"、"题材是福禄寿"、"工艺是镂空雕"。如果都塞进分类表，分类会爆炸。我加了一张标签表tag，再用关联表artwork_tag实现作品和标签的多对多关系。查询的时候，用户可以点标签筛选作品，后端就是一个简单的连表查询：

SELECT a.* FROM artwork a INNER JOIN artwork_tag at ON a.id = at.artwork_id INNER JOIN tag t ON at.tag_id = t.id WHERE t.name = '樟木' AND a.status = 2 ORDER BY a.view_count DESC;

多对多关系在MyBatis-Plus里需要自己在XML里写SQL，或者用条件构造器分步查询。我实际用的是先查出符合条件的作品ID，再IN查询作品表，数据量小的时候性能完全没问题，而且代码更好理解。

3.3 订单状态机设计：交易不只是"下单"两个字

交易模块如果不认真设计，后期会非常痛苦。我给订单表orders设计的核心字段包括：order_no、user_id、artwork_id、quantity、total_amount、receiver_name、receiver_phone、receiver_address、status、created_at。

订单状态我定义了五种：0待付款、1待发货、2待收货、3已完成、4已取消。毕设项目里不需要真的接入支付接口，付款动作可以用一个模拟接口完成，但状态流转逻辑不能少。比如用户下单后订单是0，调用模拟支付接口后变成1，传承人发货后变成2，用户确认收货后变成3，超时未付款则允许取消变4。

这里有个容易忽略的点：每张订单里必须存购买时的商品快照。什么意思？商品价格可能调整、商品可能下架，但用户的订单金额不能跟着变。所以我把artwork_title、artwork_cover、price_snapshot都冗余存储在订单表里。这个设计来自一个实际教训：有一次我把商品下架之后，老订单的封面图全挂了，数据永远不能只依赖关联查询。

3.4 文化交流相关的表设计

社区模块我的设计是：帖子表 + 回复表 + 点赞记录表。帖子表字段有id、user_id、title、content、view_count、like_count、comment_count、status、created_at；回复表挂在帖子下，用post_id关联；点赞记录表用user_id和post_id唯一约束防止重复点赞。

用户发布帖子前必须登录，这个校验放在后端接口里做，不能只靠前端按钮隐藏。管理员如果发现违规内容，可以把帖子status置为1，前端列表就不会展示。社区内容审核在文化类项目里格外重要，因为这个平台面向大众，内容的健康度是最基本的底线。

4. 核心模块落地：从接口设计到功能闭环

4.1 作品列表与详情页的分级查询

作品展示是用户进门第一眼看到的东西，性能体验直接影响留存。我在实现上做了两个优化：列表页用分页查询，配合Redis缓存热门作品ID；详情页用VO对象聚合，一次查询把作品基本信息、图片列表、传承人简介、工艺步骤全部带出来，避免前端发多个请求。

MyBatis-Plus的分页查询非常方便，selectPage方法传入Page对象和条件构造器就能完成。关键代码大概长这样：

public IPage<ArtworkVO> queryArtworkPage(Integer pageNum, Integer pageSize, String keyword, Long categoryId) { Page<Artwork> page = new Page<>(pageNum, pageSize); LambdaQueryWrapper<Artwork> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(Artwork::getStatus, 2) .like(StringUtils.hasText(keyword), Artwork::getTitle, keyword) .eq(categoryId != null, Artwork::getCategoryId, categoryId) .orderByDesc(Artwork::getViewCount); IPage<Artwork> result = artworkMapper.selectPage(page, wrapper); // 再批量查询每个作品的封面图和所属传承人名称，组装成VO返回 return convertToVO(result); }

like方法里面的第一个参数是布尔条件，关键字为空时不拼这个条件，这个写法可以避免字符串拼接出错，挺实用。

作品详情页的多图展示，我单独建了一张artwork_image表，每张图片按sort字段排序。前端拿到的是一个由多个URL组成的数组，可以自己实现缩略图轮播，不必依赖第三方插件。我在后端返回的VO里直接放List<String> imageList，JSON序列化出来就是一个数组，Vue那边用v-for渲染就行。

4.2 传承人认证与作品审核的闭环

传承人认证流程是这样的：用户在个人中心点击"申请成为传承人"，填写真实姓名、从艺年限、擅长技法，上传证明图片；数据写入artist表，状态默认为0（待审核）；管理员在后台看到待审核列表，点通过就把状态改成1，驳回时填驳回理由。

作品审核也是类似的流程：传承人发布作品后，作品状态为1（待审核），管理员审核通过后变成2（已上架）。这个设计有效避免了垃圾内容直接出现在前台。实现审核接口时，我额外做了一个小功能：管理员审核通过作品时，系统自动给传承人发一条站内消息，告诉他作品已上架。站内通知表非常轻量，但让平台显得有人情味，答辩演示的时候效果也不错。

认证和审核的接口都不复杂，本质上是更新状态字段，关键反而在权限控制：必须是"传承人"角色才能调发布作品的接口，必须是"管理员"角色才能调审核接口。这个我在所有Controller上通过JWT解析出的角色做判断，写了一个简单的注解切面来控制。

4.3 文化交流：发帖、回复、点赞与热度排序

交流社区的前端页面长得很像轻量论坛。用户在首页能看到帖子列表、按最新或最热排序，点进帖子可以看正文、回复、点赞。发帖页有一个标题输入框和内容文本域，后端接收后做一下敏感词过滤，然后插入数据库。

这里值得说的是"最热排序"的实现。我起初想用view_count + like_count * 2的公式在SQL里实时计算，但数据量大了之后性能不好。后来改成Redis里维护一个帖子热度ZSet，每次有人浏览帖子就把score加1，每次点赞加5，定时任务把前20名的帖子ID同步到一张热度缓存表里。这算是用最简单的办法实现了类似热门排序的效果，毕设阶段足够用了。

帖子点赞防重复我用的是唯一索引：user_id和post_id联合唯一。点第二次赞时先查询存在不存在，存在则删除记录且帖子like_count减1，不存在则插入且加1。当然高并发下有原子性问题，但只要保证两个操作在事务里，毕设场景完全够。实测几轮点赞流程，数据一致性没出过问题。

4.4 交易闭环：下单扣库存用事务加乐观锁

交易模块是整个系统里最容易写BUG的地方，尤其是库存扣减。我第一版代码是这么写的：先查库存，库存大于0就执行update。这在单用户测试时一切正常，一旦两个用户同时下单就会出问题，两个请求都查到库存还剩1，结果两单都成功了，库存变负数。

正确做法是乐观锁更新，SQL写成这样：

UPDATE artwork SET stock = stock - 1, sale_count = sale_count + 1 WHERE id = #{artworkId} AND stock >= 1;

然后通过int affected = artworkMapper.update(...)判断受影响行数，如果affected == 0说明库存不够，抛出业务异常回滚订单创建。这样即使两个请求同时到达，数据库的行锁也会保证只有一个更新成功。订单生成和库存扣减必须放在同一个事务里，用@Transactional标注，任何一个环节失败都能回滚。

订单号生成我推荐"时间戳+用户ID+随机数"的组合，比如20250612 + userId + 四位随机数，再用字符串拼成一个订单号。虽然不保证全局唯一，但对数据库加个唯一约束足以满足毕设场景。真实电商网站也不会用这么简单的方式，但作为毕设来说，能把逻辑讲清楚比盲目模仿高深方案更实在。

5. 让它真正成为"数字传承载体"：五个进阶设计

5.1 工艺步骤的结构化展示

普通电商的商品详情是图文混排的长页面，但木雕作品的"过程"比"成品"更值得看。我在数据库里加了craft_step表：id、artwork_id、title、description、image、sort。传承人发布作品时，可以逐条添加工序，比如第1步画稿、第2步打坯、第3步修光，每步配图和文字说明。

前台展示时，作品详情页多了一个"制作工艺"Tab，前端用步骤条组件渲染，图片可以点击放大。实测下来，用户停留时间明显比只看成品图要长。这个功能最大的意义是"数字化传承"不再是概念，而是让年轻人真正看得懂一件木雕是怎么做出来的。

5.2 知识库与搜索推荐

知识库我单独做了一张knowledge表：id、title、content、category、dynasty、region、author、created_at。内容来源可以是公开资料整理，比如介绍东阳木雕的历史、材质分类、代表性技法。搜索功能我用的是MySQL的LIKE模糊匹配，虽然不高级，但胜在简单可靠。

前台首页有个"文化知识库"入口，用户按分类浏览或搜索关键词。后台管理提供文章管理界面，管理员可以编辑发布。这块内容让网站的信息架构丰富了很多，也方便被搜索收录。你如果时间充裕，还可以把知识库和作品做关联推荐：文章里讲"浅浮雕"技法时，下方自动推荐使用该技法的作品。

5.3 防伪标识与版权保护的可实现方案

非遗手工艺品和普通商品最大的区别是一物一作，价值高、仿冒风险大。在毕设里我不可能做真正的区块链存证，但我实现了一个简化版防伪方案：每件作品上架时自动生成一个唯一的"作品编号"，规则是DB + 分类码 + 流水号 + 随机字符，这个编号通过二维码生成组件渲染成图片，打印出来可以贴在包装上。

用户扫码后会进入作品详情页，看到编号、传承人、材质、工艺步骤等完整信息。这个功能实现成本很低，但讲课时能讲出价值：防伪是文化交易平台和普通电商的重要区别。我在后台还加了一个"编号查询"功能，用户输入编号就能看到这件作品的真伪信息。

5.4 在线定制的需求建模

很多客户买木雕不是买现货，而是"我要一幅60厘米的松鹤延年挂屏，用樟木"。这个需求在普通订单里不好表达，所以我加了定制模块：custom_order表包含user_id、artwork_category、size_desc、material、description、reference_image、expected_price、status。

用户提交定制需求后，管理员在后台可以看到待受理的列表，能分配给对应的传承人。传承人接单后可以留言沟通，如果双方确认，再把定制单转化为一个正式订单。这个功能让平台从单纯"卖现货"延伸到"接定制"，也更贴近木雕行业的真实交易习惯。毕设展示时，这条业务线非常能体现你对行业的理解。

5.5 后台数据可视化与"传承地图"

后台管理不能只有表格，那样既不好看也不好讲。我用开源图表组件做了一张数据大屏：左侧是"作品分类占比"饼图，中间是"近30天作品浏览量趋势"折线图，右侧是"传承人地域分布"柱状图。统计接口用SQL的GROUP BY聚合，比如作品分类占比的核心查询：

SELECT c.name, COUNT(a.id) AS cnt FROM category c LEFT JOIN artwork a ON c.id = a.category_id GROUP BY c.id, c.name

“传承地图”我做得更简单：给传承人表加了一个region字段，前端用地图组件按城市标记数量。这算是把非遗传承人的地域分布可视化，有一定的展示价值。可视化面板我做成了/admin/dashboard页面，每次答辩演示的时候打开这个页面，效果比打开一堆表格强得多。

6. 开发周期中踩过的坑、调试思路与部署建议

6.1 文件上传路径：Windows和Linux的致命差异

这是我踩得最深的坑。开发阶段我把上传目录写成了D:/upload/works，本地跑得好好的，部署到Linux服务器后所有图片上传直接报500，控制台提示找不到目录。原因是服务器上根本没有D盘，而且代码里用字符串拼接路径，在Linux下会拼出错误的结果。

后来我把存储路径抽到配置文件里，用@Value注入，同时在上传接口里做了目录自动创建：

String uploadPath = fileConfig.getUploadPath(); File dir = new File(uploadPath + File.separator + "works"); if (!dir.exists()) { dir.mkdirs(); }

File.separator会自动根据操作系统使用/或\，这样兼容性就没问题了。Nginx那边对应一段静态映射配置，就能通过URL访问上传的图片：

location /images/ { alias /data/woodcarving/images/; autoindex on; }

如果你把Spring Boot的jar包和上传目录放在一起，要特别注意打包时不要包含uploads目录，否则重新部署会把旧的图片文件冲掉。我的经验是把数据目录独立在项目外，比如/data/woodcarving/，代码目录和数据目录分开。

6.2 LocalDateTime序列化与MySQL时区问题

另一个经常出问题的点是时间。MySQL 8.0默认的serverTimezone是UTC，Spring Boot连接时如果不指定时区，查询出来的时间会和本地时间差8小时。我在JDBC连接串里明确写了serverTimezone=Asia/Shanghai，就解决了大部分时区问题。

但还有一个更隐蔽的坑：后端返回的LocalDateTime字段，前端JSON里显示成一串数组，比如[2025,6,12,10,30,0]，这个问题本质是Jackson默认不序列化JDK8时间类型。解决办法是在实体字段上加注解：

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8") private LocalDateTime createdAt;

或者全局配置一个ObjectMapper来统一处理。我选了注释方案，因为更直观，一个字段一个字段加也不费事。如果不想在每个字段上都加注解，可以在启动类里注册一个Jackson2ObjectMapperBuilderCustomizer的Bean配置全局格式。

6.3 跨域、字符集、前端联调的老三样

前后端分离开发时，浏览器控制台报跨域错误是非常常见的事情。有的人会开浏览器插件绕过，但正确的做法是后端允许跨域或者生产环境用Nginx反向代理。我开发时用CORS配置，部署时改成Nginx把/api/请求代理到Java服务，这样前端访问的是同源地址，就不存在跨域问题了。

数据库建表的时候，我把字符集统一设置成utf8mb4，因为utf8在MySQL里存不了生僻字和特殊符号，而木雕作品名称里经常有异体字。连接串里也要加上useUnicode=true&characterEncoding=utf8，确保数据写入读取都走UTF-8。

前端联调阶段，我习惯用Vite的代理功能来转发请求，开发地址是http://localhost:5173，接口请求代理到http://localhost:8080，这样生产环境的请求路径和本地开发保持一致。如果你不是前后端分离，而是模板引擎方案，可以跳过这一段。

6.4 打包部署的完整链路

项目收尾阶段，我梳理了一套完整的部署流程，照着做基本不会翻车。第一步在项目根目录执行mvn clean package打包，生成可执行的jar文件；第二步把jar上传到服务器，上传目录和图片目录分开；第三步用java -jar启动前先确认服务器上装了JDK和MySQL，并且MySQL的账号密码和配置文件里一致。

启动命令我放在了一个start.sh脚本里，方便重复运行：

#!/bin/bash nohup java -jar woodcarving-platform.jar --spring.profiles.active=prod > app.log 2>&1 & echo "Application is running"

配置分离用的是Spring Boot的profile机制：application-dev.yml放本地配置，application-prod.yml放服务器配置。启动时加--spring.profiles.active=prod指定环境。这样本地调试和服务器部署互不干扰，数据库地址、文件路径这些敏感配置都集中在profile文件里，不用每次部署前手工改代码。

6.5 给准备做同类项目的人四条实在建议

第一个建议是先画页面原型再写代码。我开始的时候直接建表写接口，结果前端页面做出来和想象中差距很大，又回去改表结构，白白浪费了几天的返工时间。现在回头想，拿纸笔画一遍每个页面长什么样，数据字段需要哪些，就能少走很多弯路。

第二个建议是管理好自己的版本。我用Git做代码管理，核心功能每个版本打一个tag，比如"v1.0作品模块""v1.1社区模块"。有一次大改数据结构出了问题，直接回滚到上一个tag，五分钟就恢复了。没有版本管理的话，这种问题通常只能手工改回去，非常痛苦。

第三个建议是答辩讲项目要讲业务和设计的权衡，不要一上来就报技术名词。评委老师更想听你为什么要这样设计表、为什么这样处理并发、为什么这个模块用Redis，而不是听你报了一遍Spring Boot的启动流程。把这些"为什么"提前写进PPT，比堆架构图有用得多。

第四个建议是文案和数据要提前准备。我花了很多时间在网上搜集东阳木雕的历史资料和作品图片，整理成结构化数据后才开始做展示模块。数据是文化类网站的底气，页面再漂亮，内容空洞一眼就能看出来。

7. 项目收尾的一些个人心得

做完这个项目，我最大的体会是：非遗数字化看起来是个"文科题"，实际上对数据建模的要求并不低。它既要照顾文化内容的展示深度，又要保证交易流程的严谨性，还要管理社区内容的健康度，任何一个环节单拎出来都是完整的产品问题。

我到现在还记得第一次把工艺步骤图文跑通时的感觉：一件木雕作品从画稿到成品的流程图真切地展示在网页上，那一刻比拿到一个完美的订单状态机更有成就感。技术上这个项目没有用任何高深框架，但它让我学会了如何把一个行业的真实需求翻译成系统设计，而不是照着教程抄一个电商Demo。

如果你也准备做类似的文化类毕设，我的建议是：去了解这个行业真正的内容结构，不要把它当成普通的商城来写。数据库里多一张工艺步骤表、多一个传承人认证流程，系统的价值和深度就完全不同。后续如果还有时间，这个平台还可以扩展3D模型展示、短视频教程、线下展览报名这些功能，每一条路都值得探索。