企业官网建设流程全解析

如果你最近在找毕业设计选题或者练手的全栈项目，Java基于springboot+vue的摄影设备租赁管理系统这个名字应该不陌生——电商类的租赁业务天生适合做前后端分离架构，业务逻辑清晰，技术栈又主流。我拿到这个项目需求后，花了三个周末从零把它撸了出来，从数据库设计到权限控制再到订单流转，踩了不少坑。这篇文章不打算给你平铺直叙地复述 CRUD，而是把整个系统的设计思路、实现要点和我实际开发中遇到的问题整理出来，希望能让你少走点弯路。

先说清楚：这个系统面向的是摄影器材租赁场景，核心业务就是“用户浏览设备 -> 下单 -> 支付押金与租金 -> 商家发货 -> 用户使用 -> 归还 -> 结算退款”。听起来不复杂，真做起来涉及到的点不少：多角色权限（管理员、商家、普通用户）、设备库存与档期管理、订单状态机、押金和租金计算、图片视频展示，甚至还有消息通知。如果你正在准备 springboot 相关的面试，这套系统里藏着的 cron 定时任务、AOP 日志、Redis 缓存、事务回滚、自定义异常处理，全是现成的面试题素材。

1. 这个系统到底在解决什么问题：租赁业务的真实痛点

不做不知道，一细想才发现摄影设备租赁跟普通商品买卖完全是两码事。如果你直接套用商城那套“下单即减库存”的逻辑，第二天商家就得找你退款。

1.1 租赁和售卖的本质差异：时间维度才是主角

普通电商的核心是“SKU + 库存数量”，卖一件少一件；而租赁的核心是“SKU + 设备编号 + 时间段”。一台索尼A7M4在9月1日到9月5日被人租走了，那这台机器在9月5日之前对其他人就是不可用的状态，但它本身依然在库里，而且9月6日之后又可以继续接单。所以库存模型必须从“还剩几件”转成“设备档期表”。

这就是很多人做租赁系统第一个理解偏差的地方。我开始也傻乎乎地给商品表加了个stock字段，后来真正做订单冲突校验时才发现必须引入equipment_sku（设备规格）和equipment_instance（具体某一台设备）两张表分开设计。SKU 管租金定价、押金、图片这些静态属性；Instance 管设备序列号、当前状态、累计租出次数这些动态属性。档期表再单独建一张equipment_schedule，每次下单前查询某台设备在指定时间段是否空闲。

提示：如果你的项目答辩时被问到“为什么这么设计”，这条就是最核心的亮点——你把“时间”作为了一等公民来建模，而不是简单地在库存数量上做加减法。

1.2 用户痛点和角色诉求

我从实际使用角度梳理了三类角色的关键诉求：

• 普通用户（租客）：最关心设备拍出来的效果（所以要有作品展示）、租金是否透明（押金多少、超时怎么算）、取还方式、以及订单的完整状态跟踪。
• 商家/管理员（门店）：最关心设备不被“双订”（同一台机器同一时间被两个人下单，线下必打架）、订单异常怎么处理（用户逾期不还、设备损坏），以及每台设备的出租率和收益统计。
• 系统本身：要有完整的日志审计、数据一致性保障、权限隔离。毕竟涉及押金和资金流转，出问题就是事故。

这个系统最终交付时，我把它分成了用户端（Vue 单页应用）和管理端（同一套 Vue 工程，通过路由和权限动态区分），后端统一 SpringBoot 提供 RESTful API。搜索热词里提到的“vue 动态路由”在这里派上了大用场——前端根据登录用户的角色动态注册路由，管理员能看到“设备审核”、“订单管理”、“数据统计”菜单，普通用户只能看到“浏览设备”、“我的订单”、“个人中心”。

2. 技术选型与工程搭建：为什么是 SpringBoot + Vue

这套组合近些年在中小型管理系统里几乎是统治级的存在。选择它们不单是因为“大家都在用”，而是各有不可替代的理由。

2.1 SpringBoot 后端：约定优于配置，省心省力

做这个项目时我用的 Java 版本是 17（长期支持版本，企业里用得最多），SpringBoot 用的 2.7.x。之所以不用 3.x，是因为当时 3.x 刚出不久，部分第三方 starter 兼容性还不稳，而且 2.7 自带的安全配置、Redis 集成资料非常多，踩坑成本低。

SpringBoot 给我的体感是：它把“让它跑起来”的成本降到了最低。内嵌 Tomcat，一个java -jar就能启动；自动配置让数据源、Redis、MyBatis 这些组件的集成变成一个注解或一个 yml 配置项的事；最重要的是生态完备，做鉴权有 Spring Security，做接口文档有 Knife4j，做缓存有 Spring Data Redis，CRUD 层有 MyBatis-Plus 兜底。这套组合下来，开发效率比传统 SSM 翻了一倍不止。

一个值得说的细节是分层架构。我按照“Controller -> Service -> Mapper”三层来组织，但额外加了一层DTO和VO的严格分离。Controller 入口接收 DTO（前端传入的数据模型），Service 层做业务处理，最后用 VO（视图对象）把数据返回给前端。这样做的最大好处是：前端拿到的字段永远是你想暴露的字段，而数据库实体里的密码、状态码这些敏感信息不会因为@JsonIgnore漏配就泄露出去。项目的包结构大概是：

com.example.photorental ├── controller // 接口层，只做参数接收和结果封装 ├── service // 业务逻辑层，事务边界在这里 ├── mapper // MyBatis-Plus 的 Mapper 接口 ├── entity // 数据库实体映射 ├── dto // 接收前端参数的封装对象 ├── vo // 返回给前端的数据封装对象 ├── config // 配置类（Security、Redis、跨域） ├── common // 统一返回结果、异常处理、常量 └── utils // 工具类（JWT工具、日期工具等）

2.2 Vue 前端：组件化开发和动态路由

前端用的 Vue 2 + Element UI。其实现在新项目很多已经切到 Vue 3 + Element Plus 了，但 Vue 2 的稳定性和既有组件库生态依然很强，尤其对毕设这种中小型项目，Element UI 的表格、表单、日期选择器开箱即用，能省掉大量从零手搓 UI 的时间。

我按照“视图层 -> 路由层 -> 状态管理层”来组织前端工程。重点说一下 Vue 的几个核心机制在这个项目里的实际用法：

• 组件化：设备卡片、订单步骤条、图片上传弹窗都抽成了复用组件。比如“设备卡片”组件接收一个设备对象，内部自己处理封面图、租金标签和点击跳转，在首页列表、搜索结果页、商家设备管理页都能复用。开发时改一个地方，三处生效。
• Vue Router：全局前置守卫里判断用户是否携带 token，没有就强制跳转登录页；登录后根据角色动态 addRoutes，保证低权限用户看不到管理路由。
• Vuex（Pinia 的思路更现代，但 Vue2 用 Vuex 最稳）：保存用户信息、登录状态，多个页面组件共享“当前用户是否登录”、“当前用户的购物车/收藏”这类全局状态，避免页面刷新就丢失登录状态的尴尬。

前端开发里最容易被忽略但最容易出问题的是代理配置。本地开发环境下，前端跑在 8080 端口，后端跑在 8081 端口，直接跨域。我在vue.config.js里配了 devServer 的 proxy：

module.exports = { devServer: { port: 8080, proxy: { '/api': { target: 'http://localhost:8081', changeOrigin: true, pathRewrite: { '^/api': '' } } } } };

这样请求/api/equipment/list时，开发服务器会把请求转发到后端的/equipment/list，完美规避代理跨域问题。注意后端还有个 CORS 配置我留下了坑位——生产环境是 Nginx 反代，不需要后端开 CORS；但如果你是本地前后端分离联调，后端的 WebMvcConfigurer 里也要提前配好跨域，否则前端代理配好了也会被浏览器拦。

2.3 环境准备里那些容易卡住的点

热词里“vue安装及环境配置”和“springboot配置”都在搜，说明很多人卡在项目启动这一步。我分享一下我的环境组合和注意点：

• JDK：17。用 IDEA 的话记得在 Project Structure 里把 SDK 指对，否则 Maven 编译会报 “java: 无效的源发行版”。
• Maven：3.8.x。本地仓库一定要确认配了阿里云镜像，不然拉依赖慢到怀疑人生。我见过同学用默认仓库拉一个 springboot 项目等了半小时的。
• Node.js：16.x。Vue 2 配 Node 16 是最稳的；Node 18 以上偶尔会有 OpenSSL 哈希算法的问题，需要export NODE_OPTIONS=--openssl-legacy-provider，不如直接上 16 省事。
• MySQL：5.7 或 8.0 都可以。注意数据库的timezone参数，连接串里加上serverTimezone=Asia/Shanghai，否则日期字段查出来会比实际慢 8 小时。
• Redis：Windows 版 Redis 直接到 GitHub 下压缩包，解压后redis-server.exe启动即可。后端项目里用 Redis 做缓存和 token 黑名单。

环境是最没有技术含量但又最容易劝退新手的环节。多数时候不是你不会写代码，而是环境版本错位导致的玄学报错。我的建议是：固定一套经过验证的版本组合，不要追新，JDK17 + SpringBoot2.7 + Vue2 + Node16 这套组合我验证过，稳定。

3. 数据库设计：租赁系统的地基与状态机

我在设计表结构时花的时间最多，因为后面所有功能的难易程度，都取决于表设计是否合理。改了三次模型才定稿，这里把最终版的核心思路分享给你。

3.1 核心表结构和字段要点

整个项目一共 12 张表，核心的几张如下：

几个关键设计决策再展开说说：

订单号生成。很多人直接数据库自增 id，但租赁订单要强校验和防猜测，我用的是“日期 + 随机数”的方式，比如20250901103045001，用Redis的 INCR 生成自增序号，拼上时间戳。这样可以保证全局唯一且不暴露业务量级。顺便一提：主键在订单表这种高并发写入的业务里，我反而用了ASSIGN_ID（雪花算法），而不是数据库自增，避免分库分表和性能瓶颈的隐患。

金额字段一律用 BigDecimal，绝不用 double/float。摄影设备动不动押金几万块，double 产生的精度误差在退款对账时是灾难性的。虽然编程规范里写了无数遍，但做这个项目时见到不少同学用 double 存钱的，看得我脊背发凉。更安全的做法是大家在数据库字段设计上直接统一DECIMAL(10,2)，Java 侧对应BigDecimal。

时间字段统一用 datetime。有人喜欢用 int 存时间戳，查询和前端展示都得来回转换，纯属给自己找麻烦。datetime 配合 Java 8 的 LocalDateTime，MyBatis-Plus 自动映射，非常好用。

3.2 订单状态机的设计：一张图想清楚所有流转

租赁订单的状态是最容易写崩的逻辑，因为关联了支付、发货、归还、结算、退款多个环节。我最终用枚举常量来统一管理，状态流转如下：

PENDING_PAYMENT 待支付 -> PAID 已支付(押金+租金) 或 CANCELLED 已取消(超时未支付自动取消) PAID 已支付 -> SHIPPED 已发货(商家发货/用户自提) 或 REFUNDED 已退款(用户发货前申请取消，扣除少量手续费) SHIPPED 已发货 -> IN_USE 使用中(用户确认收货) -> RETURNING 归还中(用户提交归还申请，填写物流或到店归还) IN_USE 使用中 -> RETURNING 归还中 RETURNING 归还中 -> COMPLETED 已完成(商家验收通过) -> OVERDUE 已逾期(验收发现逾期，收取超时费) -> DISPUTED 争议中(设备损坏有争议) COMPLETED 已完成 -> 结束 OVERDUE 已逾期 -> 结算后 COMPLETED 完成 DISPUTED 争议中 -> 仲裁后 COMPLETED 或 报损 CLOSED

这套状态流我直接用数据库的status字段存储整数状态码，在 Java 侧定义一个OrderStatusEnum来维护合法流转路径。每次状态更新时先校验当前状态是否允许到达目标状态，不允许的直接抛异常。有些教程会把状态改得随意——比如从“待支付”直接改到“已完成”——这在现实中不可能，一旦被审计查出问题就是要返工的事。

为什么不用 String 类型存状态名字符串？一是存字符串容易拼错还不好做索引，二是后端判断时靠equals("PAID")比status == 2的写法要啰嗦得多。用整数+枚举映射，Service 里写if (order.getStatus() == OrderStatusEnum.PAID.getCode())逻辑非常清爽。

3.3 防止日期冲突的档期校验：核心中的核心

这个校验逻辑是整个系统的护城河。要实现的是：新订单的 [start,end) 时间段和已有订单的空闲档期不能冲突。

我第一次实现时直接用 SQL 去查“该设备在这个时间段有没有冲突订单”，写法是：

SELECT COUNT(*) FROM rent_order WHERE instance_id = #{instanceId} AND status IN (2,3,4,5) -- 已支付、已发货、使用中、归还中 AND start_time < #{endTime} AND end_time > #{startTime}

只要结果为 0，就说明该时间段没有占用，可以下单。这个写法简单且高效，只要查询条件里的状态集合排除掉已取消、已完成这些不影响档期的状态，就不会误判。

但在高并发场景下（比如某款热门大疆无人机同时被 10 个人抢租同一天），两个请求同时查到 0，然后都创建订单，就会“双订”。解决这个问题的常规方案有两个：

• 方案一：对rent_order表加唯一约束uk_instance_time(instance_id, start_time, end_time)，冲突时数据库直接抛 DuplicateKeyException。
• 方案二：用 Redis 分布式锁，锁的 key 是instance:lock:{instanceId}，先获取锁再查询+下单，释放锁后结束。

我做这个项目时用的是方案二 + 数据库唯一索引双保险。锁住了并发入口，唯一索引兜底极端场景，两种手段组合下来，双订问题基本从根上解决了。这也是面试时能拿出来讲的亮点——你不仅知道要锁，还知道为什么要加数据库兜底。

注意：给rent_order加唯一索引时要谨慎，start_time和end_time的组合唯一性只能在单台设备维度成立，加了instance_id一起做联合唯一索引才是对的。我第一次设计索引时差点把条件搞成 “同一用户不能同时租两台设备”，问题就大了。

4. 核心功能实现与避坑：实际开发中的硬骨头

现在进入真正写代码的部分。这一节我给你过一遍实现流程里最容易出问题和最值得讲的功能点。

4.1 注册登录与 JWT 权限控制

登录功能看起来简单，但牵扯到密码安全、token 管理、权限校验三层。密码我直接用的 Spring Security 的BCryptPasswordEncoder，用户注册时把明文密码 BCrypt 加密再入库。BCrypt 的一大优势是每次加密的盐不同，即使两个用户密码相同，密文也不同，查库撞库的成本极高，而且 Spring Security 内置了这个实现，没必要自己造轮子。

登录成功后后端生成 JWT，签名秘钥放在application.yml的jwt.secret配置项里，过期时间设为 2 小时。JWT 里只放userId和role两个关键 claim，前端拿到后存到 localStorage。每次请求带上Authorization: Bearer <token>，后端用拦截器解析 token，校验通过后往请求上下文塞一个CurrentUser对象，后续业务代码里直接调CurrentUserHolder.get()拿当前登录用户信息。

这里有个坑要提醒你：JWT 一旦签发，在过期前是无法主动失效的。用户修改密码后旧 token 依然有效。我的处理方案是把 token 的 jti（唯一标识）存到 Redis，退出登录时删除，鉴权时检查 Redis 中是否存在。用空间换安全性，完全值得。热词里搜到“springboot安全配置”和“java怎么保证数据一致性”，我觉得数据一致性在这里的体现之一就是 token 状态的一致性——你不能让 Redis 数据和 JWT 本身互相矛盾。

权限控制我用的方法是定义注解@RequirePermission("admin")，加在需要管理员权限的 Controller 方法上。拦截器里先校验 token 合法性，再判断当前用户角色能否匹配注解要求。这样比直接在每个接口方法里写if(!isAdmin) throw要优雅得多。当然，如果项目规模大一点，直接上 Spring Security + @PreAuthorize 也完全没问题，本质思路一样。

4.2 设备管理：图片上传与 Minio 集成

热词里频繁出现“minio加入到springboot”，看来很多人都在用 Minio 做文件存储。这个项目肯定也绕不开——租赁平台必须展示设备实物图，可能还要上传押金凭证、报损照片。我的方案是后端统一对接 Minio，前端通过接口获取上传地址。

Minio 是一个开源的、兼容 S3 API 的对象存储服务。为什么不直接把图片塞进 MySQL？一是数据库体积膨胀，备份恢复变慢；二是图片走数据库吞吐性能差，而 Minio 可以直接生成带签名的访问 URL，配合 Nginx 反向代理后可以走 CDN 加速。我本地用 Docker 起了一个 Minio 实例，然后后端的存储服务类封装了三个核心方法：上传、删除、生成预览 URL。

核心依赖就一个：

<dependency> <groupId>io.minio</groupId> <artifactId>minio</artifactId> <version>8.5.7</version> </dependency>

配置上注意一个隐蔽的坑：Minio 的连接地址如果写成了http://localhost:9000，那在服务器本地访问没问题，但生成的文件 URL 里 domain 会是 localhost，前端从其他机器访问肯定是 404。正确做法是单独配置一个minio.endpoint给 SDK 做 API 调用，再配一个minio.public-url给前端拼接文件地址——生产环境一般走 Nginx 反代域名。

业务实现逻辑是：设备实体里不直接存图片二进制，而是维护一个image_url字段存 Minio 的 object key。展示时后端根据 key 生成临时访问 URL 返回给前端。如果需要多图展示，就建一个独立的equipment_image表，一对多关联。

4.3 订单流程：事务、并发和定时任务

下单是整个业务里最需要保证数据一致性的地方。用户点击下单，后端要同时做四件事：校验档期冲突、冻结设备（把 instance 状态改为“锁定”）、生成订单（待支付）、扣减设备可用状态。这四步必须在一个事务里完成，任何一步失败都整体回滚。

Spring 的@Transactional注解保证了这一点。需要注意的是事务的边界控制——我之前习惯在 Controller 层直接调 Mapper，后来改成所有写操作都经 Service 层，事务只加在 Service 方法上。事务边界太宽（Controller 层加事务）会把接口的耗时全部算在事务里，锁持有时间变长；太窄（只在 Mapper 上）则中间业务异常无法整体回滚。这个教训是我在一个订单漏写回滚导致测试数据脏乱后总结出来的。

支付与退款。项目里没有接入真实支付宝/微信支付（毕设和个人项目很难拿到商户号），我用的是模拟支付：下单后调一个pay接口，后端生成一条支付流水记录，把订单状态从“待支付”改成“已支付”。退款同理，生成退款流水并更新状态。这样既保证了业务流程完整，又不涉及真实资金安全。

如果你真的想接真实支付，思路是：前端调后端createPrepayOrder，后端调微信/支付宝的下单接口拿到支付参数返回给前端，前端拉起支付组件，支付成功后微信/支付宝回调你的 notify_url，后端验签后处理订单状态。这里要注意回调接口必须做幂等处理——同一条支付成功通知可能因为网络重试到达多次，处理逻辑必须保证重复消费不产生重复流水。

逾期归还检测，这个功能可能出乎意料，但它是租赁系统的灵魂。用户租期结束还没归还，系统要自动计算逾期费用并更新订单状态。我用 Spring 的@Scheduled(cron = "0 0/30 * * * ?")每半小时扫描一次所有“使用中”的订单，发现end_time已过且未发起归还的就自动置为“已逾期”，逾期费按天计算。定时任务的幂等性是个很容易被忽略的问题——同一订单在连续两次扫描中可能都被命中，如果更新逻辑没有判断“只有使用中状态才能改为逾期”，就会把已完成订单也误伤。所以任务方法里第一步永远是检查当前状态。

4.4 前端页面逻辑：Vue 的核心实现点

Vue 侧有两大块是搜索引擎里高频出现的：“vue播放m3u8”和“vue路由参数”。

关于 m3u8。摄影平台有时候会上传设备实拍视频或教程，m3u8 是常见的流媒体分片格式。Vue 里播放 m3u8 我用的video.js，核心配置是：

import videojs from 'video.js'; import 'video.js/dist/video-js.css'; // 需要在 main.js 里注册 vhs 插件 require('@videojs/http-streaming'); // 组件里调用 this.player = videojs(this.$refs.videoPlayer, { sources: [{ src: this.videoUrl, type: 'application/x-mpegURL' }], controls: true, fluid: true });

这个功能我一开始以为需要后端专门处理流切片，实际上 m3u8 是播放器的事，后端只需要把能访问到的 m3u8 地址传过来即可。前提是视频文件可以做跨域访问，或者由 Nginx 做转发。

Vue 路由参数的传递。设备详情页的跳转必然涉及到列表页携带设备 id 给详情页，最常见的两种方式：

• 路径参数：this.$router.push({ path:/equipment/${id}})，详情页里this.$route.params.id获取。
• 查询参数：this.$router.push({ path: '/equipment/detail', query: { id: id } })，详情页里this.$route.query.id获取。

两者区别：路径参数在 URL 上更美观，刷新后依然能正确取到；查询参数在分享链接时更灵活，但 URL 会多出?id=xxx。我建议详情页一律用 path + params 的方式。

还有一个 vue-router 的经典坑：同一个路由组件在参数变化时不会重新触发 created 生命周期。比如从/equipment/1跳转到/equipment/2，组件实例被复用了，created 不会再次执行，页面显示的依然是上一台设备。解决办法是在组件里 watch$route：

watch: { '$route'() { this.fetchDetail(this.$route.params.id); } }

这个细节很多人不知道，线上改 bug 时发现了才明白。写进你的项目总结里，比罗列“用了 vue-router”有说服力得多。

5. 权限细化与安全防御：不该被看到的页面和数据

权限系统在租赁平台里尤为重要，因为管理员和普通用户的操作范围差异巨大，而且涉及资金数据和用户隐私。

5.1 后端接口权限控制

我用的方式是“自定义注解 + 拦截器”。定义注解@RequireRole("ADMIN")，加在管理端接口方法上；拦截器里统一拦截所有/api/**请求，解析 JWT 里的角色字段，和注解要求比对。普通用户接口不需要加注解，但会被拦截器统一校验 token 是否存在。

这样还有一个额外好处：管理端的接口即使前端路由没暴露，攻击者直接拼 URL 调接口也会被后端拦截。前后端分离项目里，前端路由隐藏只是“视觉安全”，真正的安全边界一定在后端接口校验上。我见过不少同学前后端都做了菜单隐藏，但后端接口不设防，这是很严重的功能缺失。

5.2 数据权限隔离

用户只能查看自己的订单、自己的报损记录，不能在 getUserList 接口传一个 userId 就拿到别人的数据。这个功能实现起来不复杂，就是所有查询订单的 Service 方法都必须带上userId参数：

public PageResult queryUserOrders(Long userId, Integer page, Integer size) { LambdaQueryWrapper<RentOrder> wrapper = new LambdaQueryWrapper<>(); wrapper.eq(RentOrder::getUserId, userId) .orderByDesc(RentOrder::getCreateTime); return pageQuery(wrapper, page, size); }

管理端查询所有订单是另一个接口queryAllOrders，加@RequireRole("ADMIN")注解。两个接口互不干扰，职责清晰。千万不要图省事写一个通用接口，通过参数里的 userId 决定查询范围——这是越权漏洞的温床。

5.3 统一异常处理与接口返回格式

你肯定不希望后端一报错，前端就弹一个“Failed to fetch”或者裸奔出一堆异常堆栈。我定义了一个统一的返回体：

{ "code": 200, "message": "success", "data": { } }

后端用@RestControllerAdvice统一捕获异常，业务异常返回 code 500 + 具体信息，参数校验异常返回 code 400 + 字段错误详情，未登录返回 code 401。前端在 axios 响应拦截器里拿 code 统一处理，遇到 401 自动清 token 跳登录页。这套机制成熟稳定，而且能非常体面地展示你的工程化能力。

提示：建议给参数校验配一个专门的@Validated+@NotNull组合，DTO 字段上做校验注解，这样接口入口处就把脏数据挡在外面，不用每个 Service 方法都写 if 判断。这也是面试能聊两分钟的细节。

6. 部署与上线：把项目从本地搬到服务器的那些坑

项目写完不部署，始终像没走完最后一步。热词里频繁出现“springboot版本太高”“javaspringboot项目构建方法”“springboot配置”，说明这个环节确实拦住了不少人。

6.1 后端打包与启动

SpringBoot 项目打 jar 包我用的是 Maven 的package生命周期，关键是在pom.xml里配置了spring-boot-maven-plugin，才能把依赖打成一个可执行 fat jar。命令行启动：

mvn clean package -DskipTests java -jar photorental-server.jar --spring.profiles.active=prod

这里有一个经典的坑：SpringBoot 版本和 Maven 版本不匹配导致打包报错。3.x 的 SpringBoot 要求 Maven 3.6.3 以上，2.7 版本则比较宽容。如果你的环境是新版 Maven 配旧版 SpringBoot，偶尔也会有兼容提示，可以试试降低 Maven 版本或升级 SpringBoot 版本。

6.2 前端构建

Vue 项目构建生产包：

npm run build

构建产物在dist/目录，部署时交给 Nginx 托管。Nginx 配置里需要注意两个地方：

第一，dist目录里路由是 vue-router 的 history 模式时，静态资源路径会对不上，需要配location / { try_files $uri $uri/ /index.html; }。不做这步，刷新详情页直接 404。

第二，接口转发。前端请求/api时 Nginx 要代理到后端的 8081 端口：

location /api/ { proxy_pass http://127.0.0.1:8081/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

前端 axios 的 baseURL 写/api，这样开发环境的 Vue 代理和生产环境的 Nginx 代理用同一套规则，代码不用改。

热词里“基于springboot的校园教职员工考勤管理系统”也出现了，说明不少人在做类似的管理系统项目。不管是考勤还是租赁，部署阶段的坑基本都是同一批，把这套流程跑通，换业务只是改需求的问题。

6.3 性能与数据安全

最后聊两件很多毕设项目都不做的事，但它恰恰是区分“能跑”和“可用”的关键。

• Redis 缓存热点数据。设备详情页和首页列表是流量最大的接口，每次查询都打 MySQL 很浪费。我在 Service 层加了缓存：根据列表查询条件生成 key，缓存放 JSON 串，Redis 过期时间 10 分钟。设备上下架、修改价格时主动删缓存，保证一致性。这就是热词里的“java怎么保证数据一致性”的实践案例——缓存与数据库的一致性，靠的是主动失效策略，而不是被动过期。
• 日志与数据备份。关键操作（登录、支付、订单状态变更、权限变更）接入了 AOP 切面自动写操作日志，后端异常也统一记录到日志文件。数据库每天凌晨用 cron 任务自动备份，分配到不同目录，保留最近 30 天。这个项目你可能只需要用 Navicat 手动导一次 SQL，但上线的话自动备份是底线。

写在最后的个人体会

把这套系统从头到尾做完，我最强烈的感受是：做项目跟背面试题完全是两回事。背了八百遍 Spring 事务传播行为，真到写订单状态更新时才发现事务加错层级会导致回滚失效；看了无数篇 Minio 教程，真到配置 public-url 时才明白为什么本地跑得好好的、部署上去图片全裂。踩过这些坑，再去看那些面试题，才真正理解了它们在解决什么问题。

如果你打算在这个项目基础上继续扩展，我建议你优先考虑这几个方向：一是引入消息队列，把下单后的短信通知（Redis 延迟队列或 RabbitMQ）做成异步的，解耦也提速；二是把前端升级到 Vue 3，用 Composition API 重写设备列表和订单流程；三是给系统增加一个简单的推荐逻辑，根据用户历史订单推荐同品牌或同焦段的设备。这些方向每一条都能让项目在功能深度和代码质量上再上一个台阶，也都能在简历的项目描述里写出清晰的亮点。

希望这篇分享能帮到你，尤其那些正准备拿这个题目做毕业设计或者入门全栈的朋友。有问题可以在评论区直接问，我看到都会回复。