企业官网建设流程全解析

每到毕设选题季，后台总有人问类似的句式：“能不能推荐一个难度适中、又有完整业务闭环的Spring Boot项目？”我通常给出的备选里，排在前三的就是“美食分享系统”。

这个选题看着朴素，但它背后是一个标准的“用户—内容—互动”三角结构：注册登录、图文发布、图片上传、评论点赞、搜索分页、数据统计，后端开发常见的核心问题几乎都覆盖到了。对比之下，电商项目往往陷进库存、支付、秒杀之类的复杂度泥潭，而管理系统又容易退化成纯粹的增删改查，缺少业务纵深。美食分享系统正好卡在一个“有得写、写得起、答得了”的难度区间，非常适合作为毕业设计或简历上的练手项目。

这篇文章不是教科书式的教学文案，而是记录我在开发同类系统时沉淀下来的技术思路、架构取舍和实际踩过的坑。如果你是准备选这个题的学生，或是想把它作为个人项目的在职开发，可以从里面直接拿走一套能落地、能演示、能讲清楚的方案。

1. 这个题目到底在做什么：项目定位与需求拆解

1.1 美食分享系统的核心其实是“社区”

很多同学看到“美食分享”四个字，第一反应是“做一个菜谱管理”。如果真按这个思路去做，系统会变成一个菜谱表单的CRUD，毫无竞争力。

这个系统的本质是内容社区，而不是菜谱数据库。用户发布自己做的菜，附上食材清单、步骤图和个人心得；其他用户看到后可以点赞、收藏、评论；大家还可以搜索感兴趣的关键词，比如“红烧肉”“空气炸锅”。这三个动作组合起来，才构成系统的完整价值闭环。

所以我在给项目划分功能时，反复强调的是：内容发布是起点，互动是增长点，搜索是引流点。三者缺了任何一个，系统都会显得单薄。

1.2 功能板块怎么拆才不会失控

给系统做需求拆分时，我是按“前台用户侧”和“后台管理侧”两条线来拉的，具体分了四个核心板块。

第一块是用户体系：注册、登录、退出、个人资料维护、头像修改、个人主页。这里要处理的技术难点在于密码存储、登录态管理、角色权限。很多学生在这里图省事直接用明文密码，这在大作业里可能没人管，但放到演示环节被老师问一句，就很容易翻车。

第二块是内容体系：菜谱的发布、列表展示、详情查看、编辑、删除。这块的难点是图片怎么存、怎么异步上传、列表和详情怎么优雅展示。

第三块是互动体系：评论、点赞、收藏、关注作者。这块考验的是表设计能力和接口的防重复设计。比如同一个用户对同一个菜谱只能点赞一次，再点一次是取消点赞，这就不是单纯insert一条记录那么简单。

第四块是检索体系：关键词搜索、分类筛选、按时间或热度排序、分页加载。这里需要思考搜索是走数据库模糊查询，还是引入全文索引；分页是用物理分页还是逻辑分页。

四块并不算多，但组合起来恰好能让整个项目有血有肉。

1.3 用户角色与权限边界

这个系统里有两类角色，我在设计时就把权限边界写清楚了。

普通用户：可以浏览美食内容，登录后发布菜谱、编辑自己的菜谱、点赞收藏评论他人内容、关注其他用户、管理个人资料。

管理员：除了普通用户的能力，还需要内容审核、用户禁用、数据概览。内容审核这块需要做一个简单的列表页，给管理员提供“下线”或“删除”不合格菜谱的操作入口。

权限建议用最轻量的方案实现：在用户表里加一个role字段，拦截器里判断一下就行。没必要上Spring Security的重型权限模型，做毕设和练手项目要的是清晰、可控、能讲清楚，而不是把框架功能堆满。

2. 技术选型与架构设计：先搭骨架再填肉

2.1 技术栈选择及理由

在做技术选型时，我的原则是：主流的、容易部署的、文档够多的、面试聊起来有价值感的。最终我给这个项目定的组合是Spring Boot 2.7.x + MyBatis-Plus + MySQL 8.0 + Redis + JWT，前端用Vue 3搭建，或者直接用服务端渲染的Thymeleaf做保底方案。

这里要单独说下为什么用MyBatis-Plus而不是纯MyBatis。纯MyBatis需要手写大量XML映射，单表CRUD写多了全是重复劳动，项目节奏会被拖慢。MyBatis-Plus封装了通用的单表Mapper方法，分页插件也很好用，能让我们把精力放在业务逻辑而不是机械的SQL上。但它又不是完全的“黑盒”，复杂多表查询仍然需要手写XML，这样在答辩时也可以解释底层SQL映射怎么回事。

Redis在这里面承担两个职责：一是缓存菜谱的详情数据和热点列表，减轻数据库压力；二是存登录状态或Token黑名单。如果不想引入Redis，也可以用单机Session，但我就明确说，用Redis加JWT这套组合，在简历上写出来会比Session方案好看很多，而且实际开发中也是目前主流的做法。

2.2 分层架构与包目录规划

项目的包结构按照经典三层来划分，我常用的模板是：

com.example.foodshare ├── controller // 接口层，接收请求和参数校验 ├── service // 业务层，防业务逻辑 ├── mapper // 数据访问层，MyBatis-Plus的Mapper接口 ├── entity // 数据库实体类 ├── dto // 前端交互数据对象 ├── vo // 视图返回对象 ├── config // 配置类（MybatisPlus、Redis、WebMvc等） ├── interceptor // JWT拦截器 ├── utils // 工具类（JWT等） └── common // 统一返回Result、异常处理

Controller只做参数接收、基础校验和路由转发，不写业务；Service负责业务规则和事务控制；Mapper负责数据存取。这种分层的好处是：每个类职责单一，出错时能第一时间定位问题在哪个环节，答辩时解释起来也清晰。

另外要强调dto和vo不能省。很多项目所有对象都用实体类往上抛，结果接口返回了密码字段，这很尴尬。正确做法是：接收前端参数用DTO，返回给前端的用VO或Map，实体类只在Mapper层使用。

2.3 数据库表设计的关键细节

数据库是这类系统的命根子，我梳理一下这五张核心表。

用户表：

id BIGINT 主键 username VARCHAR(32) 用户名，唯一 password VARCHAR(64) 加密后的密码 nickname VARCHAR(32) 昵称 avatar VARCHAR(255) 头像地址 intro VARCHAR(255) 个人简介 role TINYINT 0普通用户 1管理员 status TINYINT 0正常 1禁用 create_time DATETIME

菜谱表：

id BIGINT user_id BIGINT 发布人 title VARCHAR(64) cover VARCHAR(255) 封面图 ingredients TEXT 食材列表 steps TEXT 步骤说明 category_id INT 分类ID like_count INT favorite_count INT comment_count INT status TINYINT 0正常 1下线 deleted TINYINT 逻辑删除 create_time DATETIME update_time DATETIME

评论表：

id BIGINT post_id BIGINT user_id BIGINT parent_id BIGINT 0表示一级评论，否则是回复的评论ID content VARCHAR(500) create_time DATETIME

点赞表和收藏表结构类似，核心是：

id BIGINT user_id BIGINT post_id BIGINT create_time DATETIME UNIQUE KEY uk_user_post (user_id, post_id)

唯一索引非常关键。它能在数据库层面保证同一个用户不会对同一个菜谱产生重复点赞，避免并发下出现脏数据。业务代码里可以先查再插，但并发场景下查和插不是原子的，必须靠索引兜底。

3. 从零到可演示：核心功能实现与实操过程

3.1 登录注册与JWT认证

登录注册是项目的门面，我一定建议先把它跑通。注册逻辑其实简单，两个重点：一是密码不能明文存，二是用户名必须唯一且规范校验。

密码加密直接使用Spring Security里面集成的BCryptPasswordEncoder，它能把同一个密码加密成不同结果，同时自带盐值，比MD5加盐更安全。用法上只需要两步：注册时encode，登录时matches。

JWT登录流程我建议这样落地：

1. 用户提交用户名密码，UserService.login校验通过后生成Token。
2. Token里只放userId和role这类非敏感信息，过期时间设置为24小时。
3. 前端把Token存到localStorage，每次请求在Authorization头里携带。
4. 后端用一个拦截器统一解析Token，校验失败直接返回401。

核心代码如下：

@PostMapping("/login") public Result<String> login(@RequestBody LoginDTO dto) { User user = userService.login(dto); String token = jwtUtil.generateToken(user.getId(), user.getRole()); return Result.success(token); }

@PostMapping("/register") public Result<Void> register(@RequestBody RegisterDTO dto) { userService.register(dto); return Result.success(null); }

JWT工具类里包含生成和解析两个方法，重点是设置过期时间时用Date类型，注意别和LocalDateTime混用。

拦截器注册时，需要放行登录、注册、以及菜谱列表和详情这类公开接口。千万不要图省事把所有接口都拦上，否则前端还没登录就连列表都看到不了。

3.2 菜谱发布与图片上传

图片上传是这个项目最容易卡壳的地方。核心问题有两个：一是如何生成不重复的文件名，二是如何保证文件类型和大小是可控的。

我的做法是：用UUID + 原文件后缀作为文件名，按日期分目录存储。比如：

/upload/202506/6f8f6f8a-xxxx.jpg

后端保存代码大致如下：

public String upload(MultipartFile file) { String originalName = file.getOriginalFilename(); String ext = originalName.substring(originalName.lastIndexOf(".")); // 校验后缀，只允许 jpg/png/gif/webp if (!allowExt.contains(ext)) { throw new BizException("不支持的文件类型"); } String datePath = new SimpleDateFormat("yyyyMM").format(new Date()); String fileName = UUID.randomUUID().toString().replace("-", "") + ext; File dir = new File(uploadPath + "/" + datePath); if (!dir.exists()) { dir.mkdirs(); } file.transferTo(new File(dir, fileName)); return "/upload/" + datePath + "/" + fileName; }

存数据库时不要存全路径，只存相对路径。前端拼接时通过配置的访问前缀来拼完整URL，这样以后换成对象存储时就只需要改一处配置。

这里有几个细节坑：

第一，要在配置文件里设置静态资源映射，否则浏览器访问/upload/**会404。

spring: web: resources: static-locations: classpath:/static/, file:${upload.path}

第二，spring.servlet.multipart.max-file-size默认只有1MB，需要调大，一般放到5MB~10MB，同时限制单次请求的总大小。

第三，图片校验不能只看后缀，最好用工具读取文件的Content-Type甚至魔数，否则一个改名为.jpg的可执行文件也能被传上去，这是安全隐患。

3.3 分页列表与搜索

列表页是用户进入系统后最先接触的页面。为了兼顾性能和实现成本，我选择使用MyBatis-Plus的分页插件配合数据库模糊查询。

分页参数我统一处理为page和size。接口返回的结构是总条数、总页数、当前页数据列表。这里我强烈建议用自定义的PageVO统一包装，不要直接返回MyBatis-Plus的Page对象给前端，因为Page里有很多字段是前端用不到的。

搜索功能如果数据量在万级以内，直接用LIKE就够：

LambdaQueryWrapper<Post> wrapper = Wrappers.lambdaQuery(); if (StringUtils.isNotBlank(keyword)) { wrapper.like(Post::getTitle, keyword); } wrapper.eq(Post::getDeleted, 0); wrapper.orderByDesc(Post::getCreateTime);

如果数据量大，再考虑引入全文索引或搜索引擎，但毕设阶段先不过度设计。

排序规则我给列表页设计了两种：最新和最热。最热不是简单地按点赞数排，而是用“点赞数 + 收藏数 + 评论数”加权得到一个热度值，这样更能反映内容质量。这个热度值可以做成一个冗余字段存到表里，也可以查询时用order by表达式计算。建议直接存冗余字段，定时或者每次互动后更新，否则列表页每次请求都要全表计算，性能扛不住。

3.4 点赞、收藏、评论互动

互动模块比较考验细节。以点赞为例，我先说目标行为：用户点赞后，菜谱点赞数加一，按钮变成“已点赞”；再次点击取消，点赞数减一。

实现这套行为需要两个步骤联动：操作like_record表增加或删除记录；同时更新post表的like_count字段。这两步必须放在同一个事务里，否则会出现“点赞记录存在但数量没加”这类脏状态。

用事务注解是最简单的做法：

@Transactional(rollbackFor = Exception.class) public void like(Long userId, Long postId) { // 1. 判断记录是否存在 // 2. 存在则删除，数量-1；不存在则插入，数量+1 }

但这里还有一个并发问题：两个请求同时判断“不存在”，同时插入，由于唯一索引的存在，不会产生重复记录，但like_count可能加两次。处理方式是先让插入或删除操作执行，再根据影响行数决定是否更新计数，或者用数据库的INSERT ... ON DUPLICATE KEY UPDATE这类原子操作。我自己更推荐的做法是：先执行DELETE，如果影响行数为1，说明是取消点赞；否则执行INSERT，捕获唯一索引异常，并在异常分支里再当作取消点赞处理。这个方案虽然代码多看几行，但并发下是安全的。

评论模块建议设计成两级评论模式。一级评论直接挂在菜谱下，二级评论是针对某条一级评论的回复。前端展示时，二级评论不需要无限递归，最多两级就够了，否则前后端都会变得很复杂。查询评论时先取出所有一级评论，再批量查出二级评论，在内存里组装成树形结构，性能完全可以接受。

List<CommentVO> result = new ArrayList<>(); for (CommentVO parent : parentList) { List<CommentVO> children = childMap.getOrDefault(parent.getId(), List.of()); parent.setChildren(children); result.add(parent); }

这条逻辑我单独拿出来讲，是因为它代表了“宁可在内存里组装，也不要写递归SQL”的工程经验。递归查询在数据量小的时候没问题，但一旦复杂化，SQL难维护，监控也难做。

4. 开发过程中踩过的坑与排查记录

4.1 数据库时区问题导致时间差八小时

我第一次跑通项目时，发现列表里创建时间普遍比当前时间早八个小时。排查一圈，问题出在MySQL连接串上没有指定时区。

当数据库和服务端所在时区不一致时，JDBC驱动会按默认状态转换时间，最常见的结果就是差八小时。解决办法是在数据库连接参数里明确指定服务器时区：

jdbc:mysql://localhost:3306/foodshare?serverTimezone=Asia/Shanghai&useUnicode=true&characterEncoding=utf8

同时，在Java代码里我统一使用LocalDateTime接收数据库的datetime类型，不走Date，避免Date默认时区带来二次偏移。时序图层面踩的坑往往不会立刻暴露，而是等到演示给老师看时才暴露，所以配置要一次到位。

4.2 跨域配置把前端卡在门外

前后端分离部署时，前端Vue运行在8080端口，后端Spring Boot跑在8081端口，浏览器默认会把这类请求拦截掉。解决跨域的方法很多，最简单的是实现WebMvcConfigurer的addCorsMappings方法：

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

这里有一个容易被忽略的细节：如果设置了allowCredentials(true)，那么allowedOrigins不能用*，必须用allowedOriginPatterns或者明确列出前端地址，否则浏览器还是会拦截。这个坑我在本地联调时卡了一个下午，后来才发现是通配符和凭证冲突的问题。

4.3 上传图片后访问不到

图片上传成功后，页面上的IMG标签显示404。这个问题有80%的概率是静态资源映射没有配置对，另外20%是网络路径问题。

排查思路是有顺序的：先用浏览器直接访问图片的完整URL，例如http://localhost:8081/upload/202506/xxx.jpg，确认返回404还是403，如果是404，检查是否配置了资源映射，检查配置文件里的路径是否为绝对路径；如果是403，检查目录权限和操作系统文件权限。还有一个隐蔽问题：路径里如果包含中文或空格，浏览器不会自动转义，前端拼接URL时要注意encodeURI。

毕设阶段我建议把图片保存在本地磁盘后用静态映射暴露，这样最简单。但如果在简历里想写得更有亮点，可以把存储层抽象成接口，本地实现一套，对象存储实现一套，以后切换存储方式时不需要改业务代码，这种抽象设计在答辩时是很加分的。

4.4 逻辑删除和唯一索引打架

我给菜谱表设置了逻辑删除字段deleted，然后给业务字段加了唯一索引，结果上线测试时发现：删除一条记录后再添加同一条记录，数据库提示唯一索引冲突。

原因很清晰：逻辑删除并没有真正删掉数据，记录还在表里，唯一索引仍然生效。解决方式有三种。

第一种，不用逻辑删除，直接物理删除。简单，但会丢掉历史发文数据，对社区类系统不太友好。

第二种，唯一索引改为复合索引，把deleted也放进去。比如UNIQUE KEY (username, deleted)，这样同一用户名在deleted=0下只能存在一条，而历史逻辑删除的记录可以保留多条。这个方案最常用，我最终也选了它。

第三种，删除时把业务字段改名，比如追加一个删除时间后缀。这样能保证唯一性，但代码里到处都是拼接逻辑，不推荐。

这个坑就是典型的“没想清楚逻辑删除的语义”造成的，但也正因为遇到过，才能在答辩时拿出一个像样的技术深度问题来讲。

5. 答辩前的准备与常问问题

5.1 为什么选择这套架构

答辩时老师最常问的第一句话往往是“你为什么要选择这套技术栈”。回答时不要只说“因为主流”，要有对比意识。

例如，在讲Service层时可以说：我选MyBatis-Plus是看重它的单表通用能力和分页插件，但多表关联场景仍然手写SQL，保证复杂查询的执行效率可控。在讲登录状态时可以说：不用Session是为了让后端服务变成无状态，这样将来如果拆成多个实例部署，不需要引入Session共享组件，只要各节点校验同一个JWT密钥即可。这种回答直接体现出你思考过人、规模、演进，而不是单纯地“框架是拿来用的”。

5.2 系统的亮点和待改进点

我在准备答辩论点时，给这个项目总结了三个可以主动讲的亮点。

第一个亮是图片上传的存储抽象。本地存储和对象存储服务都实现了同一个接口，通过配置切换，这在简历上可以展开为“面向接口编程”的实践。

第二个亮点是点赞防重复。数据库唯一索引加业务原子操作，双重保障，这是一个良性的并发处理。

第三个亮点是列表页热度排序。用点赞数、收藏数、评论数加权计算热度值并冗余存储，避免了多表实时统计带来的性能瓶颈。

同时，被问到“哪里可以改进”是必答题，必须提前准备。我的答案会说三点：一是搜索可以引入专业搜索引擎或全文索引，替换掉LIKE模糊查询；二是图片压缩与CDN加速还没有做，大量图片场景下会成为瓶颈；三是推荐算法目前是简单的热度排序，后续可以基于用户行为做个性化推荐。这三点都是顺着现有系统向上演进的方向，不会让老师觉得你在找补，反而会觉得你有完整的思考链路。

5.3 演示时的几个细节建议

系统演示是答辩的重头戏，我建议按一条稳定路径来演示：注册账号、登录、浏览首页推荐列表、搜索一个关键词、点击菜谱详情、发布一条带图片的新菜谱、给自己的或他人的菜谱点赞评论、最后切到管理员账号下线一条违规内容。不要演示到一半临时想起什么点什么，路径要固定，操作要提前练熟。

另两个提醒：一是把数据库和项目的启动顺序提前确认好，不要让评委在台上等五分钟加载；二是准备好一份演示用的干净数据，里面要有至少二十个菜谱、若干条评论和点赞记录，这样列表和详情页面看起来才像一个真的有内容的系统，而不是空壳。

另外一个容易忽略的点：在后端接口返回数据处理上，我统一封装了Result结构，包含code、message、data三个字段。前端所有请求都按这个结构解析，异常也统一走全局异常处理器，不让系统原始报错信息直接暴露给用户。这个设计在演示时如果某一步操作失败了，页面只会弹出“参数错误”或“服务器繁忙”，而不是一堆堆栈信息，观感完全不一样。

这个项目后续还能怎么延伸

把美食分享系统做完，很多人以为项目就到此为止了。实际上它往上走的空间非常大。比如把菜谱内容与用户生成的烹饪笔记结合，做一个“美食日记”时间线；或者接入步骤视频，让菜谱不再只是图文；再或者加入标签体系和基于用户行为的推荐，让首页内容做到千人千面。从简历角度来看，这一步完全可以从“CRUD项目”升级成“有业务策略的内容平台”。

如果非要我给一个个人经验，那就是：不要把毕设当作交差的任务，把它当作一个能展示工程思维的作品。同样一个美食分享系统，有人说它简单，有人能讲出存储抽象、并发去重、热度排序、社区互动闭环，这中间的差距不在题目本身，而在做项目时的思考深度。把每个表设计、每个接口逻辑问一遍为什么，这个项目就不仅仅是一个学分，而是你递出去的第一张技术名片。

最后分享一个小技巧，在开发时把关键接口的文档用Swagger注解写好，并且保持Controller的注释清楚。到了写论文和答辩演示时候，你会感谢当初多写的那些注释，因为很多论述素材可以直接从里面抽出来。