企业官网建设流程全解析

1. 项目概述：这个美食网站系统到底在做什么

先把这个项目的核心成分拆开说清楚。它的关键词是几个：SpringBoot、Vue3、MyBatis、前后端分离、MySQL。把这些串起来，就是一个典型的企业级全栈练手项目——一个基于B/S架构（浏览器访问服务器）的美食网站系统。管理员在后台管理菜品分类、维护菜品信息、审核评论，普通用户在前台浏览美食列表、看详情、搜菜谱、收藏评分、发表评论，整套流程前后端各自独立开发，通过JSON格式的数据接口对接。

这类项目在技术社区里一直属于“高性价比”的选题。因为它足够完整：有用户体系、有商品（菜品）展示、有分类筛选、有评论交互、有搜索，几乎覆盖了一个业务系统最常见的所有功能形态。同时它又不至于复杂到让初学者无从下手，一个能力中等的开发者，花上一到两周业余时间，就能把整套系统从数据库设计到部署上线跑通。

适合谁来参考？三类人。第一类是正在准备面试或毕业设计的在校学生，这套项目能把前后端分离、接口鉴权、联调部署这些核心技能一次练全。第二类是刚入行不久的后端开发，想补齐Vue3前端能力，或者前端想补后端知识，用它当桥梁很合适。第三类是确实有餐饮类网站外包需求的小团队，把它作为底子二次开发，效率远比自己从零搭框架高得多。

我在写这篇文章之前，特意把这套系统的完整实现逻辑重新走了一遍。下面所有内容，都基于实际开发过程中会真实遇到的场景来写，包括踩过的坑、走弯路的地方、以及最后验证可行的解决方案。按着这套思路走，你能少走很多弯路。

2. 技术选型与方案决策：为什么是这套组合

2.1 后端选型：SpringBoot为什么是默认答案

后端框架这一层，市场上可选的不算少。Spring Boot、Spring Cloud、若依这类快速开发平台、甚至Python的Django/Flask、Go的Gin，都能做出美食网站。但为什么这套项目最终落在SpringBoot上，理由很实际。

第一是生态成熟度。SpringBoot的起步依赖（Starter）机制，把配置工作量压缩到极致。做一个美食网站，你需要的Web支持、MyBatis集成、数据库连接池、JSON解析，只需引入对应的Starter，几乎不需要手写XML配置文件。举个例子，引入spring-boot-starter-web之后，内嵌的Tomcat直接帮你把HTTP服务跑起来，不用像传统SSM项目那样配置一堆Servlet、监听器和DispatcherServlet。这个过程对新手来说非常友好。

第二是社区资料沉淀。作为一个学习项目，遇到报错时能不能在搜索引擎里快速找到解法，直接决定你的心情和效率。SpringBoot在这个体量的项目上，每类报错都有成百上千条讨论记录。相比之下，冷门框架遇到一个诡异问题可能卡你三天。

第三是就业市场的匹配度。国内Java后端岗位的需求量依然很大，而SpringBoot几乎是Java岗位的标配技能。用这套系统作为面试中的项目经历，面试官不需要额外理解框架层面的东西，可以直接聚焦在业务实现细节上，沟通成本低，也更容易聊出亮点。

2.2 前端选型：Vue3 + Element Plus的组合拳

Vue3相比Vue2最大的变化是组合式API（Composition API）。用setup语法糖写业务逻辑，代码的组织方式从“按选项拆分”变成了“按功能拆分”。美食网站这种页面数量中等、逻辑复杂度适中的项目，用Vue3做正好能体会到组合式API带来的清晰感，又不会被过于复杂的工程化配置拖住。

UI组件库我建议用Element Plus。它是Element UI的Vue3版本，表单、表格、弹窗、分页这些后台管理页面需要的组件几乎开箱即用。美食网站的管理员端（菜品管理、分类管理、评论管理）大部分是标准CRUD界面，用Element Plus能省掉大量手写CSS和交互逻辑的时间。而且它的中文文档完善，组件示例可以直接复制到代码里改，对新手极其友好。

前端工程化方面，Vite作为构建工具比Webpack体感上快一个量级。Vue3官方现在默认推荐Vite，热更新速度确实快，改完代码浏览器几乎秒级刷新，这一点在调试样式时的体感差异非常明显。

2.3 数据库与ORM选型：MySQL + MyBatis的稳定组合

MySQL在中小型业务系统里的地位不需要过多解释。它轻量、免费、文档丰富、部署简单。一个美食网站的数据量在初期最多几千条菜品和几万条评论，MySQL的性能绰绰有余。如果需要事务支持（比如用户下单支付场景），MySQL的InnoDB引擎也能很好地保证ACID特性。

ORM这一层选MyBatis而不是更“自动挡”的Spring Data JPA，原因在于它的SQL可控性。JPA让你少写SQL，但遇到复杂的多表关联查询、动态条件拼接时，JPQL和Criteria API的写法反而让人头大。而MyBatis就是明明白白写SQL，查出来是什么就是什么，对初学者来说更容易理解数据是怎么被查出来的。这个系统的核心查询——菜品分页搜索、分类联动、热门推荐排序——都是典型的动态SQL场景，用MyBatis的<if>标签拼接条件非常顺手，整个过程都在你的掌控范围内。

提示：如果你已经熟练了MyBatis，后续可以试试MyBatis-Plus。它能自动生成单表的CRUD方法，比手写Mapper接口和XML快很多。不过在项目初学阶段，我建议你先手写一遍Mapper，把SQL的来龙去脉搞明白，再考虑用增强工具提效。

2.4 前后端分离：为什么要拆开，以及拆开的代价

“前后端分离”这四个字，在现在的Web开发里已经是默认架构了。它的核心是把前端页面渲染逻辑和后端数据处理逻辑彻底拆开，两边各自独立开发、独立测试、独立部署，之间只通过HTTP接口通信。

好处非常明确。第一，团队协作效率高——前端不用等后端写完才能开工，只要提前约定好接口文档，两边可以并行开发。第二，部署灵活性好——前端是纯静态文件，扔到任意Web服务器上就行；后端是独立服务，可以单独扩容。第三，职责明确——前端管“长得怎么样”，后端管“数据怎么算”。

但拆开也带来了代价，最大的一个就是跨域问题。前端跑在localhost:5173，后端跑在localhost:8080，端口不同，浏览器就会拦截跨域请求。解决方案常见的有三种：后端加CORS配置、前端配Vite代理、部署后通过Nginx反向代理统一入口。这个坑几乎每个前后端分离项目都会遇到，我在第七章会详细说我的处理方式。

3. 数据库设计：美食网站的每一张表该怎么建模

3.1 核心表结构清单与关系梳理

一个美食网站，数据模型不需要太复杂，但也不能为了省事把所有内容塞进一张表。我的设计思路是“分包而治”，按业务边界把数据拆成五个核心模块。

其中dish表的category_id关联category表的主键，对应“菜品属于哪个分类”的关系；favorite表通过dish_id和user_id联合唯一索引实现“一个用户只能收藏同一道菜一次”；review表则承担了菜品详情页的数据聚合来源——评分均值、评论列表、评论数量都从这张表里统计。

3.2 字段设计的经验：该冗余的别省，该索引的必加

做数据库设计时，常见的误区是“为了范式牺牲性能”。但在网红类网站这种读多写少的场景里，适当的字段冗余能换来极大的查询效率提升。

举一个实际例子。菜品表里我冗余了rating和review_count两个字段，分别存储菜品的平均评分和评论总数。如果不冗余，菜谱列表页要展示评分时，就得每次都对review表做一次group by聚合查询，列表页请求量一大，数据库压力立刻上来。而冗余之后，只需要查dish表本身，或者在新增评论时顺带更新这两个字段。这属于典型的“用空间换时间”，在数据量不大的系统里完全划算。

索引方面，三个经验值得记下来：

• 外键字段必须有索引。比如review.dish_id、favorite.user_id，否则连表查询会退化成全表扫描。
• 查询频率高的组合字段加联合索引。比如favorite (user_id, dish_id)，既支持“查某用户所有收藏”，也能快速判断“该用户是否已收藏某菜”。
• 排序字段要看业务。菜品列表页按create_time倒序是最常见的默认排序，给它的索引能避免每次排序都走文件排序（filesort），实测在数据量过十万后差异非常明显。

3.3 从零建库的SQL脚本结构参考

推荐用版本化管理数据库脚本，每个SQL文件带日期前缀，比如v1.0_init.sql、v1.1_add_favorite.sql。这样后面改动字段结构时，团队协作和回溯都方便。

核心建表SQL大致长这样：

CREATE TABLE `dish` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '菜品ID', `name` varchar(100) NOT NULL COMMENT '菜品名称', `description` text COMMENT '菜品描述', `price` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '价格', `image_url` varchar(500) DEFAULT NULL COMMENT '图片地址', `category_id` bigint(20) NOT NULL COMMENT '分类ID', `rating` decimal(2,1) NOT NULL DEFAULT '5.0' COMMENT '平均评分', `review_count` int(11) NOT NULL DEFAULT '0' COMMENT '评论数量', `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态 1上架 0下架', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`id`), KEY `idx_category_id` (`category_id`), KEY `idx_create_time` (`create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='菜品表';

注意几个细节。第一，字符集一定要用utf8mb4而不是utf8，否则表情符号存不进去——美食评论里用户太爱发emoji了，踩过的坑都是血的教训。第二，价格字段用decimal(10,2)，千万别用float或double，浮点数会有精度丢失问题，金额相关字段永远用定点数。第三，update_time加上ON UPDATE CURRENT_TIMESTAMP，每次更新数据时自动变更时间，省得在Java代码里手动set。

4. 后端设计与接口实现：SpringBoot三层架构的落地

4.1 项目的包结构与分层思想

一个标准的SpringBoot后端项目，包结构上我会这样组织：

com.example.food ├── controller // 接口层：接收请求、返回结果 ├── service // 业务层：处理核心逻辑 │ └── impl // 业务实现类 ├── mapper // MyBatis数据访问层 ├── entity // 数据库实体类 ├── dto // 数据传输对象（VO、DTO） ├── config // 配置类（跨域、拦截器、全局异常） ├── common // 通用工具与统一返回结构 └── FoodApplication.java

分层架构的核心价值在于各层职责单一。Controller只负责参数接收和结果包装，不写SQL相关代码；Service处理业务逻辑，比如下单时扣减库存、注册时校验用户名唯一性；Mapper只做数据查询。这样每一层都可以独立测试，出了问题也能快速定位在哪个层面。

4.2 统一返回结构与全局异常处理

前后端分离的数据交互需要一个统一的返回格式，否则前端处理数据会非常痛苦。我这里定义一个简单的Result<T>对象：

@Data public class Result<T> { private Integer code; // 状态码，200表示成功 private String message; // 提示信息 private T data; // 实际数据 public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

配合全局异常处理器，让后端把所有异常统一转换成这个结构返回，而不是直接把一堆堆栈信息甩给前端。这样做的好处是前端统一处理错误提示，不需要每个请求都单独判断异常分支，交互体验会顺手很多。

4.3 用户注册登录：JWT无状态鉴权

用户模块是网站的基础门面。注册接口核心逻辑是：先校验用户名是否已存在，再对密码做BCrypt加密存储，最后落库。

BCrypt是一个非常推荐的选择。它是自适应哈希算法，通过加盐和动态迭代次数对抗暴力破解。哪怕两个用户密码相同，加密后的结果也完全不同，脱库了攻击者也很难反推出原始密码。很多新手直接用MD5或SHA256加密密码，这其实很危险，因为这些算法速度太快，GPU批量破解毫无压力。用Spring Security自带的BCryptPasswordEncoder就能搞定。

登录接口使用JWT（JSON Web Token）作为令牌。流程是：用户提交用户名和密码，后端验证通过后，用密钥签发一个包含用户ID和用户名的token返回给前端。前端之后每次请求都在请求头里带上Authorization: Bearer <token>，后端通过拦截器解析token，就能确认请求者的身份。

这里有个设计上的重点：JWT本身是无状态的，token里已经包含了用户信息，后端不一定要把token存进Redis。对于这类小体量系统，直接用JWT加拦截器的方案就够用了。当然，如果要支持强制下线、token续签等复杂功能，就得引入Redis存储会话状态，那是后话。

4.4 MyBatis动态SQL：菜品分页搜索的实现

菜品列表页是前台访问量最大的接口，要同时支持分类筛选、关键字搜索、分页返回。这种多条件组合查询，用MyBatis的动态SQL处理最合适。

Mapper接口定义：

List<DishVO> selectDishPage(@Param("keyword") String keyword, @Param("categoryId") Long categoryId, @Param("offset") Integer offset, @Param("pageSize") Integer pageSize);

对应的XML文件：

<select id="selectDishPage" resultType="com.example.food.dto.DishVO"> SELECT d.*, c.name AS category_name FROM dish d LEFT JOIN category c ON d.category_id = c.id <where> d.status = 1 <if test="keyword != null and keyword != ''"> AND d.name LIKE CONCAT('%', #{keyword}, '%') </if> <if test="categoryId != null"> AND d.category_id = #{categoryId} </if> </where> ORDER BY d.create_time DESC LIMIT #{offset}, #{pageSize} </select>

这里用<where>标签自动处理第一个条件前的AND，避免手工拼接SQL时多出一个WHERE 1=1或者语法错误。LIKE查询的CONCAT('%', #{keyword}, '%')是常规写法，注意不要直接写'%${keyword}%'，可能引发SQL注入漏洞。这个点面试官也很爱问，能说出来说明有安全意识。

注意：LIMIT #{offset}, #{pageSize}里的参数直接用#{offset}占位符是没有问题的，MyBatis会通过PreparedStatement传入参数。但千万别把pageSize直接拼进SQL字符串，那是注入重灾区。

4.5 文件上传与静态资源映射

菜品图片的上传，是这类管理型网站绕不开的需求。实现上可以采用本地磁盘存储加静态资源映射的方式，简单够用。

在后端配置类里，把本地路径映射成URL虚拟路径：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceMap