企业官网建设流程全解析

1. 关于这个“非遗网站系统”，先聊点实在的

如果你正打算做一个文化展示类的Web项目，或者刚好被毕业设计、课程实训里的“信息管理系统”类题目卡住，那这个“Java Web 甘肃非物质文化网站系统”应该能给你不少启发。它不是一个单纯的静态展示页，而是一套完整的、前后端分离的文化资源管理平台，核心就是围绕“非物质文化遗产”的数字化整理、展示、检索与后台维护。技术栈很明确：SpringBoot2做后端接口，Vue3做前端界面，MyBatis-Plus操作数据库，MySQL8.0存数据，还附带项目文档。说白了，这是一套可以直接运行、可以二次开发的完整源码。

这类项目的本质，不是“把网页做得好看”，而是“把分散的非遗资料变成可管理、可检索、可展示的结构化数据”。像我接触过的很多文化类站点，最大的痛点不是界面设计，而是数据怎么分类、资源怎么关联、前台怎么检索、后台怎么维护。你光有一个传承人列表还不够，还得考虑每个传承人关联着哪些项目、哪些作品、哪些视频图片，项目之间又是什么关系。这一套关系理清楚，系统架构自然就清晰了。

这套系统适合谁来参考？如果你是想快速搞懂SpringBoot+Vue3前后端分离开发流程的初学者，它能给你一个完整可跑通的工程；如果你是准备做文化展示类项目的开发者，它的表设计和模块划分可以直接抄作业；如果你只是想找一个结构工整、文档齐全的JavaWeb项目来学习，它同样够用。接下来我按实际开发的角度，把这个项目掰开揉碎讲一遍。

2. 技术栈选型与整体架构，为什么是这组合

2.1 SpringBoot2 + Vue3 + MyBatis-Plus：最稳的组合

先说后端。SpringBoot2到现在依然是JavaWeb领域最普及的框架版本，用它的原因很简单：生态成熟、资料多、招人也会问。SpringBoot3虽然新，但很多老师傅还在观望，因为SpringBoot2配合JDK8是经过大量生产环境验证的稳定组合，换成SpringBoot3就得考虑JDK17、Jakarta命名空间迁移这些问题，对一个文化展示类项目来说没必要冒险。

MyBatis-Plus选得也很合理。它本质上是个增强版的MyBatis，单表CRUD不用写SQL，继承BaseMapper就能用。比如你要查一个“非遗项目表”里的分页数据，直接：

Page<HeritageProject> page = heritageProjectMapper.selectPage( new Page<>(current, size), new LambdaQueryWrapper<HeritageProject>() .like(StringUtils.isNotBlank(keyword), HeritageProject::getName, keyword) .eq(StringUtils.isNotBlank(categoryId), HeritageProject::getCategoryId, categoryId) );

就这么几行，分页、模糊查询、条件过滤全齐了。文化类项目的数据查询条件往往很多——按分类查、按地区查、按传承人查、按关键字搜，用MyBatis-Plus的Wrapper组合条件比手写动态SQL干净得多。

前端Vue3是现在的主流方向，配合Vite构建工具，开发体验比Vue2的webpack时代舒服太多。项目里一般会用到Element Plus做后台管理界面，这个组件库的表格、表单、弹窗、树形控件直接拿来用，能给前端开发省下大量时间。前台展示页面则用Vue Router做路由切换，用Axios请求后端接口，整个前后端通过JSON数据交互，职责清楚、维护方便。

2.2 架构分层：从Controller到Mapper

整个后端工程的包结构大致是这个套路：

src/main/java/com/xxx/culture/ ├── controller/ # 接收请求、返回结果 ├── service/ # 业务逻辑层 │ └── impl/ ├── mapper/ # MyBatis-Plus的Mapper接口 ├── entity/ # 数据库实体类 ├── dto/ # 前端传参对象 ├── vo/ # 返回给前端的视图对象 ├── config/ # 配置类（跨域、拦截器等） └── common/ # 统一返回结果、异常处理

Controller只做参数接收和结果包装，不写业务；Service层放核心业务逻辑；Mapper层只做数据库操作。这种分层最大的好处是：如果以后想把某一个模块从单体拆出去做微服务，Service层可以直接复用，不用从零开始。对学习来说，这种清晰的分层也能帮你快速定位代码位置——前端报错了，先看Controller的参数接收；数据不对，去Service查逻辑；SQL有误，去Mapper找问题。

2.3 数据库设计：非遗数据的核心是“关系”

MySQL8.0这里要点个赞，它默认字符集是utf8mb4，存生僻汉字、特殊符号完全没问题。非遗项目里经常有生僻字，比如某些地方戏曲唱词、方言用字、传承人口述史资料，如果数据库还是老旧的utf8，插入特殊字符会直接报错或者变成乱码，所以utf8mb4这个细节很关键。

从功能反推数据表，一套完整的非遗网站系统至少要有这些表：

• 用户表：存后台管理员账号，一般用用户名加BCrypt加密密码，并分角色权限
• 非遗分类表：相当于目录，比如民间文学、传统音乐、传统舞蹈、传统戏剧、曲艺、传统体育游艺与杂技、传统美术、传统技艺、传统医药、民俗，这就是国家非遗十大门类
• 非遗项目表：核心业务表，包含名称、类别、级别（国家级/省级/市级）、所属地区、详细介绍、封面图、状态等
• 传承人表：记录姓名、项目关联、级别、简介、照片
• 作品表：记录代表作名称、图片、作者、简介
• 资讯/公告表：发布非遗相关动态
• 留言/咨询表：前台用户互动
• 资源附件表：存视频、音频、文档等多媒体文件路径

分类表、项目表、传承人表之间怎么关联？这里我见过不少新手踩坑：直接在项目表里加一个“传承人字段”存一串逗号分隔的ID。当时看着方便，但后面要按传承人筛选项目、统计每个传承人名下有几个项目时，SQL就变得极其痛苦。正确做法是建一张中间关联表，比如“项目传承人关系表”，记录project_id和inheritor_id的多对多关系。这样查询、统计、维护都非常灵活。

项目表的设计上，“级别”和“状态”一般用数字或字符串枚举存，比如status字段1表示上架、0表示下架，level字段存1、2、3分别对应国家级、省级、市级。前端使用的时候做一次字典翻译就行，不要直接在数据库里存“国家级”这种中文值，不然以后想改叫法就得刷库。

2.4 前后端交互与跨域处理

前端开发服务器默认跑在5173端口，后端SpringBoot跑在8080端口，这就产生了跨域问题。一般有两种解决方案：一是后端写一个全局CORS配置类，二是通过前端Vite的proxy代理转发。我在实际项目中更推荐Vite代理的方式，因为生产环境和开发环境可以用不同的代理配置，而且浏览器里请求的地址一直是相对路径，不会暴露后端真实端口。开发的时候只需要在vite.config.js里加一段：

server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } }

这样前端请求/api/project/list，Vite开发服务器就会自动转发到后端的http://localhost:8080/api/project/list。

3. 核心功能模块拆解与实操要点

3.1 前台展示端：访客能看到什么

前台是面向普通访客的，核心诉求是“看得爽、找得快”。模块安排上，一般包括首页轮播、非遗项目展示、传承人风采、作品欣赏、资讯动态、搜索站内检索等。

首页是这个项目的门面。一个合格的非遗文化网站首页，有个大轮播图是标配，放的应该是代表性项目的高清图片。轮播图下面放分类导航，用户点某个分类，直接跳转到该分类下的项目列表页。往下再看就是推荐项目卡片、最新资讯、热门传承人这几个区域。这个布局逻辑很简单——用户进来先看到整体印象，然后有明确的入口去深入了解。

项目列表页需要注意筛选功能。用户可能会按照分类、级别、地区、关键字来筛选项目。前端一般用几个下拉选择框加一个搜索框，点击查询就把条件拼成QueryString发给后端。这里有个性能优化细节：如果项目数据量大了，推荐用懒加载或者分页方式展示列表，别一口气把几千条数据全渲染到页面上。我见过一个真实案例，某文化馆的数据库里有800多个项目，一个页面全查出来，图片全加载，直接卡到滚动都掉帧。解决方式就是后端分页，每次返回12条或者24条，滚动到底部再加载下一页。

项目详情页是内容承载的核心页面。除了标题、简介、详细描述、图片这些基本信息，还应该把关联的传承人、相关作品、相关视频整合到一个页面里展示。这就要求后端在查项目详情时，不只查项目表本身，还要把关系表里的传承人、作品一起查出来组装好再返回给前端。用MyBatis-Plus，可以分别查询后手动组装VO返回，这样逻辑最直观、最容易调试。

3.2 后台管理端：管理员怎么维护数据

后台管理端是这套系统的重头戏。它的服务对象是文化馆、非遗中心的工作人员，而不是普通访客。功能上至少要有：

• 仪表盘统计：项目总数、传承人总数、作品总数、资讯总数，用几个统计卡片展示
• 项目管理：分类树形展示，对项目进行新增、编辑、删除、上架下架
• 传承人管理：维护传承人信息，关联所属项目
• 作品管理：图片上传、简介维护
• 公告资讯管理：富文本编辑、发布
• 系统用户管理：账号新增禁用、密码重置、角色分配

先说权限控制。后台不能裸奔，必须加登录验证。常见的简单实现方式是：登录成功后后端生成一个Token返回给前端，前端存在本地存储里，每次请求都在请求头带上Authorization，后端写一个拦截器对所有/api/admin/**路径做Token校验，校验不通过就返回401。前端再配一个路由守卫，发现本地没有Token就跳转到登录页。这套逻辑虽然简单，但防住了99%的越权访问。

图片上传这个功能，说简单也简单，说坑也多。如果项目部署在单机，本地存储就行：后端接收MultipartFile，按日期生成目录，存到服务器某个文件夹，然后把访问URL返回给前端。但如果以后要部署到云服务器，图片存本地有一个麻烦——服务器磁盘扩容麻烦，备份也要把图片目录单独捞出来。更稳的方案是接入对象存储服务，把图片传到云端。从学习角度，先实现本地存储，弄清HTTP上传和静态资源映射的原理，再去接对象存储会顺手很多。

3.3 检索功能的实现细节

非遗网站有个天然需求：用户可能只记得一个模糊的名字。比如“秦腔”，但数据库里存的是“秦腔（甘肃派）”，或者用户压根不知道叫什么，只记得是“甘肃庆阳那边的戏”。所以检索不能只做个精确匹配，得做成模糊搜索。

后端实现的方案是用MyBatis-Plus的like条件：

LambdaQueryWrapper<HeritageProject> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.isNotBlank(keyword), HeritageProject::getName, keyword) .or(StringUtils.isNotBlank(keyword), w -> w.like(HeritageProject::getDescription, keyword));

这样项目名称和详情描述都能匹配。但要注意，or条件如果和其他条件组合，很容易造成SQL语法上和语义上的混乱。比如你想查“名字含关键词，并且分类是传统戏剧的项目”，直接用or连接like条件会破坏原有的and关系。正确做法是给or条件包一层嵌套：

wrapper.and(w -> w.like(HeritageProject::getName, keyword) .or() .like(HeritageProject::getDescription, keyword)) .eq(categoryId != null, HeritageProject::getCategoryId, categoryId);

这个细节看起来不起眼，但实际开发里因为or和and组合混乱导致查询结果不对的场景太多了。

如果数据量进一步扩大，考虑全文检索技术，比如Elasticsearch。但对于一个几百上千条数据的非遗网站，MySQL的like已经足够，不必小题大做。

3.4 文件与多媒体资源管理

非遗项目的特点决定了系统里会有大量图片、音频、视频素材。项目表的封面图是一张，传承人头像是一张，作品详情页可能还有多张轮播图，资讯里可能还引用了视频。打一个页面，图片加载慢会影响体验。

推荐的方案是图片存相对路径，页面按需加载。后端上传图片后，把相对路径存到数据库，比如/uploads/images/2025/01/15/xxx.jpg，然后通过静态资源映射把/uploads/**指向服务器上的实际文件夹。这样数据库不存完整URL，以后如果要换域名或者迁服务器，不需要动数据库。

对视频资源，Nginx配置断点续传和切片分发是更好的选择。但项目初期，直接放一个MP4文件，浏览器用HTML5的video标签播放也没问题。

4. 从源码到部署：完整实操与问题排查实录

4.1 环境准备与本地启动

这个项目要跑起来，本地环境建议这样准备：

1. JDK 1.8或以上，推荐JDK8或JDK11
2. Maven 3.6+，用于管理后端依赖
3. Node.js 16+，Vue3项目构建需要
4. MySQL 8.0，数据库引擎
5. IDEA/VSCode作为IDE，后端用IDEA更顺手

拿到源码后，启动步骤一般是这样：

第一步，用Navicat或命令行创建数据库，库名比如culture_db，然后导入项目附带的SQL脚本。这里要注意MySQL8.0的认证插件，如果用了caching_sha2_password，SpringBoot的JDBC连接可能要加一行参数allowPublicKeyRetrieval=true，否则连接会报错。

第二步，修改后端配置文件application.yml里的数据库连接信息：

spring: datasource: url: jdbc:mysql://localhost:3306/culture_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password

serverTimezone=Asia/Shanghai这个参数很关键，MySQL8.0默认时区可能和本地不一致，有时间字段读写就会差8个小时，不加这个参数会有各种诡异问题。

第三步，后端启动。IDEA里找到启动类，运行main方法。看到控制台打印出SpringBoot的启动日志，没有报错，说明后端起来了。实测一般会在8080端口监听。

第四步，前端启动。在Vue项目根目录执行npm install装依赖，然后npm run dev启动开发服务。如果端口被占用，可以改vite.config.js里的server.port。

4.2 典型问题排查

我把这个项目里最常踩的坑总结成一张表，都是实测遇到过的：

举个例子，关于分页拦截器报错问题，很多新手忘了在配置类里注册这个Bean。MyBatis-Plus的物理分页依赖拦截器，没有它的话，selectPage方法生成的SQL会多出奇怪的limit片段，甚至直接语法报错。排查思路很明确——先看控制台打印的SQL长什么样，再反推是拦截器还是Mapper方法的锅。

4.3 生产部署与常用命令

开发完要上线，常见的部署方式是前端构建成静态文件，交给Nginx托管；后端打包成Jar包，用系统服务方式运行。

前端构建命令：

npm run build

生成在dist目录。把dist目录里的文件上传到Nginx的html目录，然后配置Nginx将请求转发到后端接口。

后端打包：

mvn clean package -DskipTests

生成一个可执行的Jar包，比如culture-server.jar。上传到服务器后，用以下命令启动：

java -jar culture-server.jar --spring.profiles.active=prod > app.log 2>&1 &

--spring.profiles.active=prod是用来切换生产环境配置的。生产环境数据库密码、文件路径等不要写在默认的application.yml里，单独放一个application-prod.yml，避免敏感信息泄露。

Nginx静态托管加接口代理的简化配置可以这样写：

server { listen 80; server_name your_domain; location / { root /var/www/culture/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这样首页和接口就一起工作了。生产环境还需要给/uploads/目录单独配置一个location，指向服务器上存放图片的路径，否则Nginx默认找不到上传的图片。

4.4 文档与二次开发建议

这个项目带了文档，这是个加分项。文档一般会包含需求分析、数据库设计、接口文档、部署说明。拿到文档后，我的建议是不要只看结果，而是对照源码理解设计过程。

比如接口文档里如果写了GET /api/project/list，返回结构长什么样、参数叫什么，就可以去后端Controller里找到对应方法，看看方法实现是否和文档一致。再比如数据库设计文档里如果画了ER图，就去MySQL里SHOW CREATE TABLE，看实际建表语句和文档有没有差异。通过这种对照式阅读，你能把一个项目从文档到代码完整串起来，学到的不只是某个功能怎么写，而是一整套设计思维。

二次开发方向上，这个项目可以扩展的地方很多。比如给前台加上用户收藏功能，需要新建一张收藏表，前端加收藏按钮，后端加收藏接口；比如增加数据统计报表，用ECharts画分类占比饼图、项目数量趋势图；再比如接入微信公众号，把前台功能搬到H5页面。这些都是很好的练手方向。

5. 文化类网站项目的通用经验总结

做文化展示类网站，跟做电商、办公系统思路不完全一样。文化类项目的核心不只是“管理数据”，更是“讲好故事”。同一个非遗项目，一张高清图片配一段有温度的介绍，比堆砌一堆字段有感染力得多。所以前台的页面设计要突出内容本身的魅力，后台则要做到极简易用，让不懂技术的文化馆老师也能顺利维护信息。

我在实际开发中遇到过这样一个场景：某单位的老师傅负责录入非遗资料，他习惯在Word文档里整理文字，再压缩打包图片发给开发团队。你说让他直接在后台系统里操作，反而觉得不习惯。所以后来我调整了思路——支持批量导入功能，用Excel模板按格式填写项目信息，然后一键导入数据库。这种贴合实际工作习惯的设计，往往比功能堆砌更受欢迎。做管理系统，界面漂亮是加分项，“老人也能顺畅地录数据”才是核心诉求。

另外要重视数据质量。非遗项目的资料整理往往比较零散，不同来源的格式不统一，有的一级分类名称叫“传统技艺”，有的地方叫“手工技艺”。后端入库前要做数据清洗和标准化，否则后续检索和统计会乱套。一张分类表，看起来很简单，但真实世界的数据往往不会像教科书那么规范。

对于准备参考这个项目做二次开发的人，我的建议是：先跑通，再改代码。不要拿到源码就埋头看文件，先把系统启动起来，注册一个管理员账号，从前台到后台把所有功能点完一遍，心里有数了，再动手改自己想要的功能。如果你要做的是一个文化馆的线上展示系统，可以在这个项目基础上把分类改成符合当地非遗名录的十大门类，补充对应的展示字段，做一做移动端适配，这样一个有模有样的作品就出来了。

最后说一个实操细节。这类文化项目永远绕不开图片和视频的版权问题。开发时用的是测试素材无所谓，但真正上线的时候，所有展示的材料都需要获得授权许可。很多项目因为资料涉及传承人口述、民间艺人表演录像等，在上线审核阶段被卡住，不是技术问题，而是版权和授权链条没走完。这个点在开发阶段一定要跟甲方确认清楚，不然最后等于白做。