企业官网建设流程全解析

做这个平台的时候，很多人第一反应是：这不就是个普通的网页展示系统吗？无非是几个页面加一个后台管理，跑起来能演示就完事了。但真正动手之后你会发现，这类项目恰恰是面试官和答辩老师最常深挖的类型——因为它表面上挂着“非遗文化展示”的名义，实际考察的是你对一个完整业务系统的整体把控能力。基于SpringBoot的勐库非遗藤条茶展示平台，从选题到交付，我把整条链路走完，今天这篇文章就照着我的实操过程，把这件事从头到尾说清楚。

这个项目能帮你解决什么问题？往小了说，是一套能提交、能答辩、能跑演示的完整毕设或面试项目；往大了说，它完整覆盖了一个真实业务系统从需求分析、数据库设计、接口开发到前后端联调的全部环节。适合两类人：一类是正在找毕设题目的在校学生，另一类是准备转Java开发岗位、想用一个有业务故事线的项目补齐简历的开发者。我下面讲的不是教科书流程，是我自己踩坑踩出来的经验总结。

1. 别把“非遗展示平台”只当成一个增删改查

1.1 勐库藤条茶是什么？为什么要做平台

先交代业务背景，免得你在答辩时被问住。勐库是滇西一个以茶闻名的古镇区域，当地有一种独特的茶树管理方式叫“藤条茶”，茶树不是常见的蓬面采摘，而是通过多年修枝，让枝条呈藤条状下垂，叶片稀疏但芽头肥壮，这种形态在普洱茶产区非常少见，已经被列入地方非物质文化遗产名录。做“非遗藤条茶展示平台”，本质上是要把这种文化用数字化的方式呈现出来，让更多人了解它的历史、工艺和产品价值。

这个选题的聪明之处在于：它有文化厚度，有可视化内容，有产品交易想象空间，一套系统里能容纳展示、资讯、产品、用户互动等多样化的功能点。跟做一个学生管理系统相比，这类项目在业务上更“有得聊”，在功能上更“有得做”，在答辩和项目复盘的时候不容易冷场。

1.2 这类项目真正想考察的技术点

表面上这是一个“信息展示平台”，但它背后实际要你综合运用的技术栈非常明确：后端要能写出规范的分层代码，前端要能完成页面渲染和交互，数据库要能设计出合理的关系模型，部署要能把项目跑起来。具体来说，核心考察点有三个。

第一是业务分层能力。你不能把全部逻辑都堆在Controller里，至少要有Service、Mapper、Entity的分层意识，这一点在代码评审时最容易被直接看穿。

第二是权限体系的构建。非遗展示平台至少包含游客浏览端和管理员维护端，两端的访问控制、路由拦截、接口鉴权，是一个不能回避的硬需求。

第三是数据可视化表达。藤条茶的宣传重点在于文化图文、产品图集、视频素材，所以文件上传、富文本内容、轮播管理这些模块的处理能力，反而比普通的CRUD更关键。

2. 技术选型：SpringBoot 为主的整体方案

2.1 后端：一主三从的常用搭配

我的方案直接采用当前Java Web项目最主流的一套组合：SpringBoot 2.x + MyBatis-Plus + MySQL 8.x + Lombok。这套组合的好处在于，SpringBoot帮你省掉了大量XML配置，MyBatis-Plus把单表CRUD的代码量压缩到一个令人舒适的程度，Lombok则消除了实体类里那些无意义的getter/setter模板。

有人可能会问，为什么不直接用Spring Data JPA？说实话，国内这个体量的项目，企业里用MyBatis系列要远远多于JPA，MyBatis-Plus在毕业设计和中小型公司里几乎是事实标准。选择它的核心逻辑不是“哪个更先进”，而是“哪个更容易被理解和维护”。你需要能在答辩时讲清楚SQL是怎么写的，MyBatis-Plus留了口子让你自定义SQL，这一点比JPA的黑盒特性更适合教学和展示。

2.2 前端与管理端：用 Vue 还是服务端模板？

前端方案有两种主流选择，你一定要想清楚再动手。

一种是用服务端模板渲染，也就是Thymeleaf。它的好处是学习成本低，前后端不分离，部署简单，一个SpringBoot应用直接搞定。适合那些前端基础比较薄弱、主要想突出后端功底的开发者。

另一种是前后端分离方案：Vue 2 + Element UI + Axios，配合后端提供的JSON接口。这种方案更贴近公司里的真实开发模式，视觉效果也明显更现代，适合把简历定位为“全栈开发”的人。我最终选择的是前后端分离方案，理由是在答辩演示时，Vue那套页面的观感比模板渲染高出至少一个档次，在展示藤条茶文化图文内容时的排版灵活性也更好。

需要提醒的是：分离方案意味着你要同时维护两个工程，联调期间跨域问题、Token传递问题都会冒出来，要做好这个心理准备。如果你时间紧张，Thymeleaf方案完全够用，但请在论文里把选型理由写充分，别给人“我不会前端才选它”的误解。

2.3 技术选型的几个避坑建议

• SpringBoot版本选2.7.x或者2.5.x，不要为了尝鲜上3.x，因为3.x基于Jakarta命名空间，很多老资料和老依赖兼容性会让你白白消耗大量排查时间。
• MyBatis-Plus的版本建议用3.5.x，老版本的分页插件配置方式已经不推荐了，新版的Interceptor配置更简洁。
• MySQL连接记得加上serverTimezone=Asia/Shanghai和useUnicode=true&characterEncoding=utf8，不然跑起来的中文乱码和时区报错会让你怀疑人生。
• Lombok在IDEA里要装插件，否则Entity类会疯狂报找不到getter/setter，这个坑每年都有新人踩进去。

3. 系统架构与角色权限设计

3.1 用户端、管理端双端口结构

这个系统从使用者的视角来划分，天然分成两个端口。

用户端面向普通访客，核心诉求是浏览藤条茶的文化介绍、非遗故事、茶叶产品、茶事资讯，能够注册登录、收藏茶品、发表留言，模拟下单。这里不需要太复杂的交互，关键是把文化内容展示得清晰有层次。

管理端面向平台运营者，核心诉求是维护内容：管理茶叶分类、维护茶品信息、发布非遗资讯、处理留言、管理轮播图、查看用户列表和订单列表。管理端的设计重心是提升操作效率，所以表格分页、条件搜索、弹窗表单、图片上传这些组件一个都不能少。

两端的核心联系在于共享同一套数据库，通过不同的接口入口访问后台服务。用户端走前台接口，管理端走后管接口，接口设计上可以通过统一的统一响应类Result来封装，保证前端拿到数据结构的稳定性。

3.2 权限控制的实现方案

权限系统我建议用轻量级方案就够了，不要一上来就引入Spring Security的深水区。原因很简单：这个项目角色就两种——管理员和普通用户，属于最简单的RBAC（基于角色的访问控制）模型。你完全可以自己实现一套基于JWT的拦截器方案，既能控制访问权限，又能在答辩时展示你对认证流程的理解。

具体实现思路是：用户登录成功后，后端签发一个JWT令牌，前端把令牌存在本地存储中，后续每个请求在请求头里带上令牌。后端写一个拦截器，放行登录、注册、浏览类接口，拦截管理端接口，校验令牌中的角色字段，非管理员直接返回403提示“无权限访问”。

这套方案比引入Security全家桶要轻得多，代码量可能不到100行，但把“认证”和“授权”这两个核心概念完整表达清楚了，我觉得比直接调框架更考验真实功力。

4. 数据库设计：一张张表拆给你看

4.1 核心四张表：用户、分类、茶品、资讯

一张好的数据库表设计，看字段语义是否清晰，看关联是否合理，看冗余是否可控。我分几张核心表来拆。

用户表t_user：主键ID、用户名、密码、昵称、手机号、头像、角色标识（1为管理员，0为普通用户）、注册时间。密码必须存加密后的密文，推荐使用BCrypt加密，不要用明文，也不要用MD5，因为这个虽然是自己写的项目，但安全习惯得从学生时代就养好。

分类表t_category：主键ID、分类名称、分类描述、排序字段、创建时间。这个表主要存藤条茶的分类，比如“古树藤条茶”“生态藤条茶”“传统工艺茶”等，分类层级保持一级就够了，做二级分类会增加树形结构复杂度，对展示型系统来说性价比不高。

茶品表t_tea：主键ID、茶品名称、分类ID、封面图、价格、库存、产地、年份、工艺介绍、详细描述、上架状态、点击量、创建时间。这张表是产品的核心，字段尽量齐全，其中分类ID与分类表形成外键关联，但在代码里不建议真的去建物理外键，逻辑外键就够了——这个问题答辩老师经常追问，你得能答出“物理外键影响扩展和性能，逻辑外键通过代码保证一致性”的理由。

资讯表t_article：主键ID、标题、封面图、摘要、正文内容、发布时间、浏览量。正文内容存放富文本HTML，注意在展示时要处理XSS问题，简单做法是在存储前过滤掉脚本标签。

4.2 留言与订单表的设计思路

留言表t_comment承载用户互动功能：主键ID、用户ID、茶品ID或资讯ID、评论内容、回复内容、评论时间、状态。这里要注意，留言可能是针对茶品的，也可能是针对资讯的，我的做法是加一个type字段区分评论类型，避免一张表里同时出现两个关联外键导致含义不清。

订单表t_order：主键ID、订单编号、用户ID、茶品ID、购买数量、总金额、收货地址、联系电话、订单状态（待发货/已发货/已完成/已取消）、下单时间。做这个模块的目的是让平台具备交易闭环的雏形，不需要接入真实支付，订单创建后走模拟流程即可，在论文里写清楚“为后续对接支付接口预留扩展空间”就行。

整个表的设计原则是：能不加冗余字段就不加，能保持字段语义单一就保持，时间字段统一用datetime类型。每张表都要有主键，建议统一命名为id，不要搞一堆自定义主键风格，这样MyBatis-Plus的默认映射才能顺利跑起来。

5. 核心功能模块的实操实现

5.1 前后端分离下的登录与 JWT

登录模块是后端的门面，实现质量直接影响整体印象。流程拆解如下：

1. 前端提交用户名和密码；
2. 后端根据用户名查询用户，用BCryptPasswordEncoder.matches()比对密码；
3. 比对通过后，使用JWT工具类生成Token，Token负载里放入用户ID和角色；
4. 返回Token和用户基础信息给前端，前端存储并跳转到首页。

JWT工具类的代码结构大致是：generateToken(User user)、parseToken(String token)、isTokenExpired(String token)这三个方法就够了。密钥用一个常量字符串存储，过期时间设置为24小时，不要设置太长，也别太短，一天是比较合理的平衡点。

这里很有必要提醒：JWT令牌的密钥不要硬编码在工具类里，至少单独放到一个配置类中，答辩时有加分效果。你可以说“密钥后续可以从配置中心动态读取，当前为方便演示放在配置类中”。

5.2 藤条茶文化展示页与富文本内容管理

藤条茶的文化页面是这个平台的灵魂。首页文化专区我规划了三个板块：历史起源、茶树形态、制茶工艺。每个板块对应一段图文介绍，这部分内容录入使用富文本编辑器。

在前后端分离架构下，我推荐用wangeditor这个国产富文本组件，接口简单，中文文档友好，后端只需要接收一个包含HTML字符串的字段，存到t_article表即可。需要注意的是：在用Thymeleaf模板方案时可以直接用th:utext输出富文本内容，但Vue分离方案里需要用v-html指令渲染，这时候一定要在后端做HTML标签白名单过滤，最基本的底线是过滤掉<script>标签，我就在本地测试时被自己存进去的<script>alert()搞出过弹窗，现场写一个简单的Jsoup过滤器能完美解决这个问题。

5.3 轮播管理与文件上传

轮播图管理是后台管理的常客。t_banner表：主键ID、图片地址、跳转链接、排序、状态、创建时间。管理端提供上传接口，前端用el-upload组件配合后端接口完成图片存储。

文件上传这块，我的建议是存储到服务器本地目录，不要往数据库里存二进制数据。具体路径可以在application.yml里配置一个upload.path，值为./upload/，图片上传后返回可访问的URL地址。注意静态资源映射配置：spring.web.resources.static-locations要加上本地upload路径的映射，否则上传的图片在前端页面上显示不出来，这个坑特别容易漏。

6. 毕设答辩与项目包装的注意事项

答辩环节最怕的不是代码有什么bug，而是“答不上来为什么这么做”。我整理了被高频追问的几个点，这些问题你提前准备好，能稳稳接住：

1. “为什么选这个题目？”——回答路径：非遗数字化保护的政策背景 + 地方特色文化传播需求 + SpringBoot技术栈成熟的工程价值。别只说“老师给的题”，要说你主动看到了什么痛点。
2. “数据库表之间关系怎么理解？”——需要能现场画出一张简单的关系图（口头描述也可以），重点讲清楚茶品-分类-留言-订单的关联逻辑。
3. “遇到的最大技术难点是什么？”——推荐讲文件上传路径映射问题或者JWT拦截白名单的配置问题，这类小而不简单的实际问题最有说服力。
4. “系统的安全性怎么保证？”——答密码加密存储 + JWT鉴权 + 后台接口角色校验，这三点完整说出来基本就过关了。

论文的书写上，注意章节结构要严谨：第一章绪论写背景和意义，第二章写相关技术介绍，第三章写需求分析，第四章写系统设计，第五章写系统实现，第六章写测试。每个章节不要写满篇流水账，重点把需求分析中的用例图和系统设计中的架构图讲透，这两处是论文的核心考察区。

答辩PPT的配色要克制，别用大红大绿。推荐用白底配一个茶色系主题色，PPT结构控制在10页左右：选题背景→技术方案→功能模块→数据库设计→核心实现→效果展示→总结展望。每页讲30秒到1分钟，总时长控制在10分钟以内，重点是让评委快速理解项目全貌。

7. 常见问题与排查技巧实录

做这个项目从开发到验收，我自己整理了7个高频问题，都配上排查思路，直接照抄能省去大量排查时间。

7.1 SpringBoot启动失败：找不到数据源

典型报错是Failed to configure a DataSource: 'url' attribute is not specified。原因通常是application.yml配置没被正确加载，或者数据源配置写错了位置。

排查思路：看target/classes目录下有没有编译后的配置文件，确认YAML文件的缩进格式是否正确，尤其是spring.datasource这个层级下，缩进多一个空格或少一个空格都会导致配置失效。这是一个极小但极常见的坑。

7.2 前端请求接口跨域报错

分离架构下跨域是必经问题。浏览器控制台会看到Access-Control-Allow-Origin相关错误。

解决方式有两种，二选一即可。第一种是后端配置跨域过滤器，简单直接：实现WebMvcConfigurer接口，重写addCorsMappings方法，允许http://localhost:8080这个前端地址跨域访问。第二种是前端在Vue工程里配置代理proxy，把/api前缀的请求转发到后端服务端口，这样浏览器看到的是同源请求，更为稳妥。

7.3 登录接口报404

这个问题的根源非常简单：管理员账号在数据库里是手动插入的，密码没有用BCrypt加密，导致登录时报错或者跳转失败。手动插入管理员数据时，必须先用在线工具生成BCrypt密文，或者注册一个用户后再去数据库把role字段改为1，比你手写SQL插入更加稳妥。

7.4 上传图片显示不出来

图片能上传但前端打不开，我用一上午才定位到问题：本地存储路径和静态资源映射路径不匹配。解决要点是：上传接口保存到E:/upload/，静态资源映射要写成file:E:/upload/，前端访问地址返回的是/images/xxx.jpg这样的相对路径，三者要一一对应才能显示。

7.5 分页查询数据对不上

MyBatis-Plus的分页功能必须配置分页拦截器才能生效，否则Page对象查出来的一直是全量数据。好消息是，如果不配置分页，调用selectPage方法时MyBatis-Plus默认不会报错，但结果就是不对。加上以下配置就能解决：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

拦截器缺失这个问题的特点是：悄悄失败，不难看，但数据永远不对劲。

7.6 打包部署后静态资源丢失

前后端分离项目打包时，前端dist目录要复制到后端src/main/resources/static目录下，然后重新打包SpringBoot的jar。我刚打包时忘了这一步，启动后访问页面全是白屏，还以为是端口被占了。另外如果用了history路由模式，刷新页面会出现404，要配置HistoryApiFallback转发，或者改用hash模式省去这个麻烦。

7.7 答辩现场电脑上没有数据库环境

这个属于低级但每年都会发生的失误。去答辩之前，一定检查自己的笔记本上有没有装MySQL服务，数据有没有导出为SQL文件，或者干脆把数据库做成Docker容器一键启动。最保险的做法是提前导出完整SQL文件，并且在现场用Navicat或命令行导入一次。如果你临时换了电脑，又没有带备份文件，那之前所有功能演示全部作废，这是项目交付时最容易翻车的一环。

8. 从交付物到自我提升：这条路值不值得走安

最后说点实在的。如果你准备做这个方向的项目，我建议不要只停留在“把代码跑起来”这个层面。试着追问自己三个问题：如果访问量变大，数据库层面该怎么优化？如果平台要接入真实支付，订单流程要加哪些步骤？如果要增加多角色管理，RBAC模型要如何扩展？能把这三个问题在脑子里过一遍，这个项目的价值就已经超越了一个普通的作业。

在我实际操作的经验里，最花时间的不是代码，而是数据的整理和测试。藤条茶相关的资料需要大量文字编辑和图片收集，每次测试都要准备好一批规范的数据，这比写界面繁琐得多。所以提前把数据规划好，是一个不太会有人提醒你但极其值得投入的准备环节。

另外一个很实用的建议是：把系统的演示流程固定下来。不要每次演示都即兴操作，提前设计一条“从首页→文化专区→茶品列表→登录→下单→后台管理→处理留言”的完整路径，每一步都提前跑通。当你已经习惯了这条固定链路，真正答辩时就完全不慌了。