企业官网建设流程全解析

每年毕设选题季，我后台私信里出现频率最高的题目之一，就是“基于Spring Boot的校园宠物咖啡店线上平台”。看到这个题目的时候，我总会提醒一句：题目截图里那个“Sping”是Spring的经典笔误，十个计算机毕设题目库里能翻出八个，但代码里可别跟着写错。抛开这个小彩蛋不谈，这个题目本身，其实是Java Web全栈方向非常适合拿来练手的一类毕设：业务场景具体、功能边界清晰、技术栈主流，做完之后你对MVC分层、接口设计、数据库建模和前后端联调的认知，会完整很多。这篇博客就把我从需求拆解到技术选型、表结构设计、核心代码实现、答辩准备的完整过程写出来，正在做或者准备做类似题目的同学，可以把它当作一份带注释的思路地图。

1. 项目需求拆解：先把业务想清楚再动手

1.1 校园宠物咖啡店到底在解决什么问题？

校园宠物咖啡店不是新物种，很多大学城附近都有。但这种店无论开在校园里还是校园周边，通常都面临几个很实际的业务痛点：

第一，高峰时段点单全靠排队，人工记单容易出错，咖啡和宠物用品混在一起的时候更麻烦。第二，会员积分多靠实体卡或者老板手记，用户不知道自己的积分，门店也难做精细运营。第三，店里如果有常驻宠物，它们的疫苗记录、健康档案、领养信息往往只是贴在墙上的一张纸，客户想查询只能问店员。第四，类似“猫咪领养日”“咖啡品鉴会”这类活动，只能靠微信群转发，触达很随机。

所以“校园宠物咖啡店线上平台”的核心价值，不是把菜单放上网那么简单，而是把门店分散的线下服务整合成一个统一入口：用户能浏览菜单、查看宠物档案、线上下单、跟踪订单、累计积分、申请领养；店员能处理订单、维护宠物档案、发布公告；管理员能做商品管理、人员管理和数据统计。

做需求分析时，我强烈建议先画一张简单的业务流程图，把“用户从产生需求到拿到咖啡/完成领养申请”的所有动作完整走一遍，再把每个动作映射成一个功能点。这个动作花不了半天，但能让你在答辩时胸有成竹地讲清楚“系统为什么要有这些模块”，而不是被老师一问需求来源就发懵。

1.2 功能模块与角色权限：减少无效设计

我习惯把平台拆成三个视角：用户端、管理端、公共支撑端。用表格整理如下：

这套权限模型不需要引入特别复杂的安全框架。如果项目使用前后端分离，用一个role字段配合Spring MVC拦截器就够覆盖；如果想给简历加分，再上Spring Security也行，但这个题目的核心工作量应该在业务流程而不是权限框架，别本末倒置。

1.3 订单状态机：把流程画出来再写代码

这个项目里最容易被答辩老师深挖的业务流就是订单，而订单的核心是状态流转。我推荐这样一组状态：

待支付 -> 已支付(待接单) -> 制作中 -> 已完成 | | v v 已取消 已取消

状态不适合用裸字符串到处判断，建议先用枚举收口，防止状态值被写错：

public enum OrderStatus { PENDING_PAYMENT(0, "待支付"), PAID(1, "已支付/待接单"), MAKING(2, "制作中"), COMPLETED(3, "已完成"), CANCELLED(4, "已取消"); private final int code; private final String desc; OrderStatus(int code, String desc) { this.code = code; this.desc = desc; } public int getCode() { return code; } public String getDesc() { return desc; } }

更新状态的方法要校验前置状态，比如只有“待支付”的订单才能“取消”，只有“已支付”的订单才能进入“制作中”。这个约束可以通过SQL条件更新实现，也可以在Service层判断。项目里把这段逻辑写清楚，答辩时主动提一句“我用了状态机思想来防止非法跳转”，含金量立刻不一样。

2. 技术选型与架构设计

2.1 Spring Boot版本到底怎么选

很多同学选版本时只盯着“最新”，这是一个常见的误区。毕业设计最怕的不是功能少，而是环境不兼容导致现场演示翻车。

我给的选型建议非常明确：

如果学校没有硬性要求，我强烈建议走Spring Boot 2.7.x。原因很现实：网上能搜到的资料和踩坑记录，超过九成都是2.x时代留下的，遇到问题更容易找到解决方案；机房和老师的机器环境也不会因为你用了最新版而自动升级JDK。等你把业务逻辑、事务、状态机这些都掌握扎实了，再升级到3.x只是一次迁徙，而不是一次重构。

另外补充一个小点：标题里的“Sping”笔误很常见，但项目名和简历上一定用正确的“Spring Boot”，至于论文摘要里如果直接引用学校给的题目，保持和教务处标题一致也是可以的。

2.2 前端方案：一体化还是分离

前端选型直接决定你三个月的项目节奏。

如果时间紧、对前端不太自信，用Spring Boot自带的Thymeleaf做服务端渲染就够了。Controller返回ModelAndView，页面里直接用th:each遍历数据，数据库查询结果渲染成HTML，不需要单独开前端工程，也不会遇到跨域问题。这种方案的缺点是交互弱、页面美感有限。

如果想让项目成品更接近真实产品，或者想把项目作为后端求职的展示作品，建议采用Vue 3 + Vite + Element Plus的前后端分离模式。后端只输出JSON，前端独立管理页面路由和状态。这样写出来的界面观感好很多，联调过程中还能积累接口设计、跨域处理、Token鉴权这些真实项目经验。代价是工时增加约三分之一，你对前端至少要有“能用”的水平。

我的建议：如果你正在准备毕业论文且时间只有两个月，选方案A；如果你是把毕设当作求职作品，选方案B并把接口文档、统一返回格式、异常处理一起做完整。这篇文章后续的代码以接口风格呈现，两种方案都适用。

2.3 核心表结构：六张表定全局

好的数据库设计能让后端开发快很多。我梳理了宠物咖啡店平台最核心的六张表：

user（用户表）

• id：主键，自增
• username：登录账号
• password：BCrypt加密后的密码
• nickname：昵称
• phone：手机号
• student_no：学号（校园场景特色字段）
• role：角色（0=用户，1=店员，2=管理员）
• points：积分余额，默认0
• status：账号状态
• create_time：注册时间

category（商品分类表）

• id、name、sort、status

product（商品表）

• id、category_id、name、description、image、price、stock、sales、status

pet（宠物档案表）

• id、name、breed（品种）、age、gender、character（性格）、health_status（健康状态）、adopt_status（领养状态）、image、remark

orders（订单表）

• id、order_no、user_id、total_amount、status、remark、create_time、pay_time、finish_time

order_item（订单明细表）

• id、order_id、product_id、product_name、price、quantity、subtotal

设计时注意三点：

金额一律用DECIMAL(10,2)，别用浮点型，否则金额计算会有精度问题。

订单明细里冗余product_name，当商家修改商品名称或删除商品时，历史订单依然能展示快照信息。这是一个合理冗余，答辩时解释为“快照设计”。

用户表和订单表之间用逻辑外键而不是数据库物理外键。物理外键在项目遇到高并发时会拖慢性能，也会给数据初始化带来顺序麻烦，所以实际开发中更常用逻辑关联。

3. 核心功能实现：代码级拆解

3.1 登录注册：Token鉴权与密码安全

用户模块是信息系统的第一道门。在前后端分离模式下，我用JWT做无状态登录：登录成功后服务端签发一个token，前端存在localStorage，后续请求在请求头附上Authorization: Bearer <token>，后端拦截器解析后把用户信息放入ThreadLocal。

核心依赖：

<dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt-api</artifactId> <version>0.11.5</version> </dependency>

登录接口的核心逻辑可以简化为：

@PostMapping("/login") public Result login(@RequestBody LoginDTO dto) { User user = userService.login(dto.getUsername(), dto.getPassword()); String token = JwtUtil.createToken(user.getId(), user.getRole()); return Result.ok(new LoginVO(token, user)); }

关于密码存储，我再说一次：用BCryptPasswordEncoder，不要用MD5。MD5虽然也能“加密”，但它没有加盐且速度极快，暴力破解成本很低。BCrypt自带盐值，每次哈希结果都不同，是主流选择。Spring Security虽然不需要整套引入，但可以单独引入spring-security-crypto依赖来使用这个类。

拦截器方面，写一个HandlerInterceptor，在preHandle方法里解析token、校验签名、把用户信息写入UserContext（本质是个ThreadLocal容器）。注意放行登录、注册、商品浏览、宠物浏览这几个公开接口，其他接口统一拦截。这个设计能体现你对权限控制的完整认知，是答辩加分项。

3.2 商品与宠物档案：CRUD也要讲分寸

商品模块即使依赖MyBatis-Plus，也只是表面上“零代码”，核心的分页、条件查询、排序仍然需要你理解。比如商品列表接口：

@Override public IPage<Product> pageProducts(int pageNum, int pageSize, String keyword, Long categoryId) { LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); wrapper.like(StringUtils.hasText(keyword), Product::getName, keyword) .eq(categoryId != null, Product::getCategoryId, categoryId) .eq(Product::getStatus, 1) .orderByDesc(Product::getSales); return this.page(new Page<>(pageNum, pageSize), wrapper); }

LambdaQueryWrapper的条件方法支持“条件成立时才拼接”的写法，比如like的第一个参数是boolean，你可以借此省掉一长串if-else。这个API用好了，代码会干净很多。

宠物档案模块是区别于普通外卖系统的灵魂功能。我建议给pet表设计一个adopt_status字段：0代表店内常驻，1代表可领养，2代表已被领养。当用户在前台点击“申请领养”时，生成一条领养申请记录，店员在后台审核并更新状态。这样就把“宠物咖啡店”的品牌故事变成了一条可运行的功能链，答辩内容也会充实很多。

3.3 下单与库存扣减：事务和并发都要考虑

下单接口是整个系统的核心重头戏，也是最容易写错的地方。逻辑包括五步：

1. 根据购物车商品计算总金额
2. 逐一校验商品库存并扣减
3. 生成订单号和订单明细
4. 累加用户积分
5. 返回支付所需的订单数据

@Transactional必须加在Service方法上，保证这五步要么全部成功，要么全部回滚。事务只加在Controller上等于没加，因为异常会在Controller层被吞掉，事务边界容易失效。

库存扣减推荐用带条件的UPDATE去实现：

int updated = productMapper.deductStock(productId, quantity); if (updated == 0) { throw new BusinessException(product.getName() + "库存不足"); }

对应SQL：

UPDATE product SET stock = stock - #{quantity} WHERE id = #{productId} AND stock >= #{quantity}

这条SQL的好处是：把“扣减库存”和“校验库存是否足够”合并成一个原子操作，数据库行锁在更新期间天然防重入，不会出现两个请求同时把库存扣成负数的情况。相比“先查库存再判断再更新”的做法，它简单且正确，用一句话就能在答辩中讲清楚，推荐大家都学会。

订单号不要用数据库自增ID直接暴露给用户，容易被看出销量。简单做法是：

String orderNo = "CK" + System.currentTimeMillis() + String.format("%03d", ThreadLocalRandom.current().nextInt(1000));

如果需要更强的唯一性，可以再拼上一个用户ID后四位，或者干脆用雪花算法。毕设阶段用时间戳+随机数已经足够。

3.4 积分变动：两张表一起记

积分模块看起来简单，但它混合了“余额更新”和“流水记录”两个动作。

用户下单成功后，要同时做两件事：一是把订单金额换算成积分累加到user.points，二是在points_record插入一条“增加”流水。两个动作在同一个@Transactional方法里完成。如果订单取消，则反过来执行：扣减积分余额、插入一条“扣减”流水，扣减时同样用条件UPDATE保证积分余额不为负。

积分的计算规则建议做成常量或配置项，比如“每消费1元积1分，生日月2倍积分”，不要散落在代码各处。答辩时如果老师问“可不可以做积分过期”，你还可以回答：记录每条积分的有效期，查询时按有效期汇总余额。这属于进阶优化，有时间可以尝试，没时间就把基础版本做扎实就好。

积分防透支的思路与库存扣减一致：UPDATE user SET points = points - #{used} WHERE id = #{userId} AND points >= #{used}。有这个意识，说明你对并发下的资源竞争有概念，答辩时非常加分。

4. 实操过程：从初始化项目到跑通全流程

4.1 项目初始化与依赖配置

用IDEA自带Spring Initializr创建工程，或者到start.spring.io生成压缩包，推荐勾选以下依赖：

• Spring Web
• MySQL Driver
• Lombok
• Spring Validation

然后在pom.xml手动补充MyBatis-Plus依赖。这里有一个非常经典的版本坑：Spring Boot 3.x对应的是mybatis-plus-spring-boot3-starter，Spring Boot 2.x用的是mybatis-plus-boot-starter。连错starter，项目启动时会报一堆莫名其妙的错误。

application.yml的关键配置参考：

server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/pet_cafe?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的数据库密码 driver-class-name: com.mysql.cj.jdbc.Driver mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

连接URL里的characterEncoding=utf8和serverTimezone=Asia/Shanghai不是可选项，而是必需项。前者负责中文不乱码，后者负责时间不差8小时。生产环境你可能还会碰到useSSL=false，本地开发建议也加上，避免MySQL 8.x默认SSL握手报一堆警告。

注意：serverTimezone=Asia/Shanghai在MySQL 5.7和8.x下都适用，但如果你用的是MariaDB，时区参数名可能有差异，最好先跑通一个最简单的查询再继续往下开发。

4.2 一个完整接口的标准开发顺序

以“用户查询自己的订单列表”为例，我建议严格按照这个顺序写代码：

1. 建好Order实体，用@TableName("orders")映射表名，字段用驼峰映射
2. 写OrderMapper接口，继承BaseMapper<Order>，需要复杂SQL时再加自定义方法
3. 写IOrderService和OrderServiceImpl，在实现里拼查询条件、做权限过滤
4. 写OrderController，接收分页参数，从UserContext取当前登录用户ID
5. 写一个统一的Result<T>返回类，定义Result.ok(data)和Result.error(msg)两个静态方法
6. 用Apifox/Postman测试，确认分页参数和响应结构正确

很多同学喜欢把业务逻辑全部写在Controller里，Service形同虚设。这不是代码量的问题，而是职责边界的问题。分层之后，单元测试可以只针对Service写，事务边界也更清晰。答辩时老师如果问“Controller和Service为什么分开”，你可以回答：Controller处理HTTP输入输出，Service处理业务规则，这样各自的可测试性和可扩展性最好。

接口的返回结构我也用一个示例：

{ "code": 200, "message": "success", "data": { "total": 3, "records": [ { "orderNo": "CK1720000000000123", "status": 2, "totalAmount": 58.00, "createTime": "2025-07-01 14:30:00" } ] } }

统一返回体的好处是前端处理逻辑简单、错误捕获统一，也方便你后续接入全局异常处理器。你可以在@RestControllerAdvice里捕获BusinessException，统一返回Result.error，这样前端拿到的错误结构永远是一致的。

4.3 前端页面与接口联调

如果选择了前后端分离，我常用的组合是Vue 3 + Vite + Element Plus。Element Plus的表格、表单、对话框组件很成熟，做管理端界面非常快；用户端页面再写几个自定义组件来突出咖啡馆的调性。

联调阶段最大的坑就是跨域。前端跑在localhost:5173，后端跑在localhost:8080，端口不同就触发跨域。后端需要放行：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedMethod("*"); config.addAllowedHeader("*"); config.setAllowCredentials(true); UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

提醒一个细节：Spring Boot 2.4以上推荐用addAllowedOriginPattern("*")，它支持携带Cookie凭证；旧的addAllowedOrigin("*")在配合setAllowCredentials(true)时会被浏览器拦截。虽然毕设可能用不到Cookie，但不建议留下这个隐患。

提示：联调阶段如果发现前端拿到的是HTML而不是JSON，先检查接口路径是否被Controller正确匹配，再检查是否被拦截器拦下重定向到了登录页。

5. 常见问题与避坑指南：答辩现场别翻车

5.1 启动报错：Mapper扫描不到或Invalid bound statement

这可能是毕业生遇到得最多的问题。通常原因就三个：

• Mapper接口忘了加@Mapper注解
• 启动类的@MapperScan路径配置错误
• MyBatis-Plus与Spring Boot版本不匹配

最稳妥的配置方式是在启动类上写：

@MapperScan("com.example.petcafe.mapper")

并把所有Mapper接口统一放到该包下。如果你使用XML文件，还要确认mybatis-plus.mapper-locations路径与XML实际存放位置一致，否则运行时会报Invalid bound statement not found。

另外提醒一个细节，启动类所在的包层级如果太浅，@MapperScan扫描不到深层包，也可能出现类似问题。建议把启动类放在com.example.petcafe的根目录，其余包作为它的子包。

5.2 中文乱码的三重排查

中文乱码是Web项目里最常见的编程问题之一，它通常不是单独一个环节的问题，而是一条链路上的三个环节。数据库层面，建表时要显式声明DEFAULT CHARSET=utf8mb4，如果表已经建好了，可以执行ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4来转换，但最省事的还是在初始化脚本里就写对。连接层面，JDBC URL必须带characterEncoding=utf8，对于MySQL 8.x驱动，字符编码参数名基本统一。HTTP层面，后端返回的响应头应该包含Content-Type: application/json;charset=UTF-8，如果你的项目用了Fastjson或Jackson，要注意序列化时是否覆盖了编码。三个层面逐一排查，中文乱码基本无处藏身。答辩时被问乱码怎么解决，直接说出这三个层面，比只回答“改一下编码”要专业得多。

5.3 本地时间与数据库时间相差8小时

本地时间与数据库时间相差8小时，这个问题几乎每个人都会遇到一次。根本原因是MySQL连接时区与本地时区不一致。统一的解法是JDBC连接URL加serverTimezone=Asia/Shanghai，同时项目里的时间类型统一使用LocalDateTime，避免使用java.util.Date。如果你用Jackson做JSON序列化，再配一层yyyy-MM-dd HH:mm:ss格式和时区，页面展示就不会出现“2025-07-01 06:30:00”这种诡异时间。补充一点：MySQL 8.x驱动要求时区必须明确，否则启动建连就会直接抛异常，所以这个参数不是可加可不加的优化项，而是必需项。

5.4 演示现场怎么保证不翻车

答辩演示是最能暴露准备不足的环节。我的实操建议是：

提前准备一份完整演示数据：5到10个商品、3只宠物档案、一个管理员账号、一个店员账号、一个用户账号，每个账号都配上合理的订单历史和积分记录。演示时沿着“登录-浏览商品-加入购物车-下单-店员接单-查看订单状态-查看积分变化”的主流程走一遍，再把宠物领养申请、公告发布这两个特色功能单独展示。避免现场编写SQL、避免打开控制台日志、避免临时改代码，这些行为会极大削弱演示的说服力。

另外，把项目的端口、数据库账号密码、初始化步骤写进README.md，放在项目根目录。这不光是为了给评审看，也是为了一个月后你自己能重新跑起来。

提示：演示用的管理员账号密码，建议在答辩前一天再测试一遍，确认没有被初始化脚本覆盖掉。

5.5 “附源码”的源码，拿到手之后该怎么办

标题里写着“附源码”，说明很多同学是带着“快速拿到代码交付”的心态来的。但根据我带毕设的经验，源码直接交稿是大忌。不管你的源码来自哪里，拿到手之后先做三件事：

第一，全局搜索并替换掉源码里的包名、作者信息和项目备注，改成以你的学号或姓名风格命名的包路径，同时把无关文件和类清干净。

第二，把核心模块至少通读一遍，然后动手修改一个小功能。比如积分规则从“消费1元积1分”改成“会员日双倍积分”，这个改动虽然小，却需要你理解积分计算入口、数据库字段、前端展示三个环节。改完之后，你对项目的掌控力会完全不一样。

第三，从零环境重新初始化数据库，跑一遍建库脚本、建表脚本、演示数据，确认项目可以冷启动。只有亲自跑通初始化流程，你才不会在答辩当天因为“数据库怎么都连不上”而翻车。

答辩老师的核心考察点从来不是“你的代码多么完美”，而是“这个项目是不是你真正做出来、真正理解的”。源码可以帮你省时间，但省下的时间必须花在理解和改造上，否则它只是一个加重你答辩负担的定时炸弹。

5.6 再补充几个容易扣分的细节

最后讲几个很多人容易忽略的细节，都属于“常规文档里不会教你，但答辩老师一定会注意”的点：

一是前端拿到的金额展示不要直接抛BigDecimal的原始值，最好在接口层就格式化成两位小数。二是所有下拉框和枚举值都提供中文描述，不要返回数字让前端自己去猜。三是在全局异常处理器中捕获BusinessException并返回统一错误码，避免把框架默认的500错误页直接抛给前端。四是上传图片功能如果做了，注意限制上传大小，spring.servlet.multipart.max-file-size默认只有1MB，建议放大到5MB并限制图片格式。这些细节单个看起来不起眼，合在一起，会让你的系统明显比那些“只跑通主流程”的毕设完整一个档次。

带过这么多轮毕业设计，我最深的体会是：像“校园宠物咖啡店线上平台”这样的题目，看起来普通，但它把真实业务的场景、数据流转和异常处理都浓缩在一个适中的规模里，非常适合用来系统性地过一遍Web开发的整个链路。如果你正在做这个题，我建议你按今天这篇文章的顺序来推进：先梳理需求，再定表结构，然后写后端接口，最后联调前端，每完成一步都跑一遍完整流程。扩展方向也留好了：预约座位、小程序端、寄养日历、消息通知，都可以在这个基础上一层层加。最后再分享一个我自己一直在用的土办法——写核心代码之前，先把数据库建好、演示数据灌进去，再开始写Controller和Service，你会惊讶地发现整个开发节奏都变得顺畅了许多。这个经验不是什么高深理论，但真的能帮你少熬好几个通宵。