毕业设计选题选礼品卡销售系统这个题其实挺有讲究。表面上它就是一个商城但你仔细拆开看里面既有商品管理、订单流转、库存控制这些电商通用能力又有卡密生成、兑换绑定、支付回调这类礼品卡特有的业务逻辑。用Java技术栈落地一个基于B/S架构、Spring Boot做后端的电子礼品卡在线交易平台刚好把Java Web开发里最常考、最常用的知识点都串起来了——从Spring Boot工程搭建到MyBatis数据库访问从Interceptor权限控制到事务并发处理每一个环节都有得写、有得练。这套系统做完你学到的不只是一个毕业设计而是一条从前端页面到数据库落盘的完整交易链路。这篇文章我按自己的真实开发节奏来梳理先讲清楚礼品卡系统到底在解决什么业务问题、角色和流程怎么拆解再讲技术选型为什么拍板用Spring Boot B/S然后是核心模块的实现思路、数据库设计和订单状态机接着是并发、幂等、安全这些容易翻车的细节最后把实操过程中踩过的坑和部署上线的方法一并交代清楚。无论是准备毕业设计、还是想找一个能写进简历的Java Web练手项目这篇都值得你从头到尾看完。1. 需求拆解礼品卡系统到底在做什么1.1 礼品卡的业务本质与典型场景很多人一听到礼品卡销售系统下意识觉得就是一个卖卡的商城。这话对了一半但更准确的定位是礼品卡是一种预付费凭证用户掏钱买下的一定面值/权益之后在指定平台或线下门店里兑换使用。礼品卡面向的场景很典型——企业采购用于员工福利、节日发放个人买来送朋友、送家人平台自己做活动发一堆定向卡密当营销工具。正因为是预付费系统关注的核心就不再只是把商品卖出去而是卡从哪来、卖出去之后怎么发出去、用户拿到后怎么用。这就引出了礼品卡系统区别于普通电商的两个关键元素卡密池一批批预先生成的、唯一的卡号 密码或兑换码代表真实的库存。状态流转卡密从可用到已售出再到已绑定/已消费每一步都必须有记录。把这个业务逻辑想明白功能模块的边界就出来了。1.2 系统角色、核心用例与一条完整链路一个可交付的礼品卡在线交易平台至少要覆盖三类使用者角色核心操作关注点游客/注册用户浏览礼品卡、加入购物车、下单、支付、查看卡密、绑定使用流程顺畅、卡密安全、订单可查运营/管理员维护卡商品信息、批量生成卡密、查看订单、处理异常管理效率、数据准确财务/客服可与运营合并核对订单与支付记录、处理退款退卡账实相符围绕这三类角色我建议把核心用例收敛成一条完整链路而不是一上来铺一堆功能用户注册登录 → 浏览礼品卡 → 选择面值/数量 → 确认订单 → 在线支付 → 系统自动发卡 → 用户查看卡密 → 用户在线绑定或复制卡密使用这条链路跑通系统主心骨就有了。至于优惠券、多商户、转赠、发票申请都属于锦上添花的扩展项不建议在毕业设计第一阶段就做进去否则工作量会失控。1.3 功能边界怎么划先做减法再做加法规划毕业设计时常犯一个错误把目标定成做一个像京东一样的礼品卡频道。结果商城架子搭了一堆真正能演示的业务闭环反而没走通。我当时的处理方式是核心功能只保留七块——用户注册登录、商品展示、购物车、订单生成、在线支付模拟支付即可、卡密自动发放、后台管理。扩展功能如批量赠卡、卡券转赠、销售统计报表放在二期规划里在论文里作为展望写清楚就行。这样做的好处很明显开发周期可控演示时有明确的故事线答辩时你能把每一个功能为什么这么设计讲明白。2. 技术选型B/S架构和Spring Boot为什么是最优解2.1 B/S架构在这个项目里的必然性选B/SBrowser/Server而不是C/S对这个系统来说几乎没有悬念。C/S方案要求用户安装客户端礼品卡平台的用户分布广、设备环境杂让每个人都装一个桌面程序显然不现实。而B/S架构下用户只需要浏览器服务端统一部署所有业务逻辑和数据都在服务器上前端只是展示和交互层。从工程角度B/S带来的直接好处是维护成本断崖式下降。运营人员调价、上架商品、修改卡密库存改完服务端页面马上生效不存在发版到客户端这种折腾事。另外B/S天然适合用户端 管理端双入口模式——两个Web应用共用一套后端服务只是页面和权限不同代码复用率很高。2.2 Spring Boot 为什么是毕业设计的最优后端框架换成十年前这种项目大概率是用Spring MVC XML配置堆出来的光配置文件就能绕晕新手。Spring Boot把这些繁琐操作全部收进约定优于配置里内嵌Tomcat解决了外部容器配置问题起步依赖Starter让引入框架变成一行依赖自动配置让数据源、Redis、消息队列这些组件开箱即用。对于做毕业设计的同学Spring Boot还有一个隐藏优势社区生态极其庞大。你遇到的90%问题在CSDN、掘金、Stack Overflow上都有现成答案。这一点在答辩前赶工时能救命。另外从就业角度说Spring Boot已经是Java后端开发的绝对主流用这个框架做毕业设计写在简历上有说服力。你甚至可以把它当面试项目来复盘Spring IoC、AOP、事务、Spring Security、MyBatis这些高频面试点全都有实际落点。2.3 前端、数据库与中间件的实际搭配后端定了Spring Boot之后前端和存储这边我的建议是前端如果优先保证毕业设计完成度用Thymeleaf服务端渲染就够了——页面里嵌数据直接渲染不用处理跨域和前后端联调。如果想在后端之外展示更多亮点就上Vue 3 Element Plus走前后端分离后端只出JSON接口。两种方案我都试过前者省时间后者涨经验按你的时间预算选。数据库MySQL 8.0是标配InnoDB引擎、事务支持、网上资料多没理由不选。缓存/中间件可选但推荐加一个Redis。哪怕只用在防重复提交或首页缓存上也能让技术方案更有层次。身份认证JWTJSON Web Token无状态方案适合前后端分离如果模板渲染也可以直接用Session Interceptor实现。2.4 模块拆分与Package结构B/S模式下的系统分层我习惯按表现层 - 业务层 - 数据访问层来组织MVC是骨架但Package结构要再细致一点方便后期扩展com.example.giftcard ├── controller // 接口层接收参数并返回结果 ├── service // 业务逻辑层事务边界在这里 ├── mapper // MyBatis数据访问接口 ├── entity // 数据库实体映射 ├── dto // 入参对象区分前端传参格式 ├── vo // 出参视图对象控制返回给前端的数据 ├── config // 配置文件Security、WebMvc、Redis等 ├── common // 通用类统一返回体、异常处理、常量 └── utils // 工具类这里有个很容易被忽视但很重要的设计Entity实体和VO视图对象必须分开。比如用户实体里有密码字段如果直接返回给前端密码字段就暴露了。用VO来裁剪字段是数据安全的第一道关。3. 核心模块实现把交易链路一步步跑通3.1 用户认证从注册登录到权限拦截用户模块是整个系统的基础。注册时密码不能明文入库我采用BCrypt加盐哈希存储。Spring Security内置了BCryptPasswordEncoder直接注入使用即可没必要自己写哈希算法。登录成功后我选择签发JWT返回给前端。JWT的核心工具代码大致如下public String generateToken(Long userId, String username, String role) { return Jwts.builder() .setSubject(username) .claim(userId, userId) .claim(role, role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }前端拿到token后每次请求在Header中携带Authorization: Bearer token。后端写一个Interceptor统一解析token并把当前用户信息放进ThreadLocal。这里要给一个提示JWT的密钥不能硬编码在代码里放在application.yml或环境变量中避免泄露。权限拦截上用角色区分访问范围ROLE_USER可以访问个人中心和下单接口ROLE_ADMIN额外访问后台管理接口。管理端页面单独设前缀/admin/**拦截器里对该路径做角色校验。3.2 礼品卡商品与库存设计理解库存 卡密池普通商城的库存是一个数字礼品卡系统里库存必须有载体。我的做法是商品表gift_card_template记录SKU信息卡密表card_secret里真实存着每一张卡。字段关系用大白话解释商品表里的库存数量只是方便前端展示的冗余字段真正的可售数量来自卡密表中状态为AVAILABLE的记录数。运营导入一批卡密商品库存就自动增加了。商品表建议字段id、card_name礼品卡名称face_value面值如500元sale_price实际售价可做折扣card_type卡类型如京东E卡、沃尔玛卡、通用券cover_image、descriptionstatus0下架 / 1上架卡密表建议字段id、card_no卡号、card_pwd卡密加密存储card_template_id关联商品status0可用 / 1已售 / 2已绑定 / 3已作废order_id被哪个订单卖出去expire_time过期时间3.3 订单创建从锁定库存到生成订单下单是整个系统最容易写崩的环节。我吃过的教训是先扣库存再生成订单还是先生成订单再扣库存两种顺序在不同场景下各有坑毕业设计里我推荐生成订单 同时扣减/锁定库存放在一个事务里完成。核心逻辑用伪代码描述是这样1. 校验商品状态必须上架 2. 生成唯一订单号规则日期时间 随机数 用户ID 3. 从卡密池中取出N张AVAILABLE状态的卡标记为LOCKED 4. 创建订单记录状态待支付 5. 提交事务这里必须加上数据库层面兜底。只靠程序判断库存够不够有并发风险我用了乐观锁思路UPDATE card_secret SET status 1 WHERE status 0 AND card_template_id #{templateId} AND id IN (...)受影响行数不等于请求数量时说明卡被抢走了立即回滚并提示库存不足。3.4 支付与发卡支付成功才是真扣卡订单创建后是待支付状态用户去支付。毕业设计里不建议真的接入微信/支付宝开放平台资质、回调地址、商户号太麻烦更合理的做法是做一个模拟支付网关用户点击支付后跳到模拟收银台确认支付后由后端模拟异步回调。异步回调是重头戏也是答辩时能讲出深度的点。真正的支付回调会重复发送多次所以接口必须幂等。我的实现逻辑是1. 接收回调请求校验签名 2. 根据订单号查订单判断是否已支付 3. 若已支付直接返回成功不做重复扣卡 4. 若未支付事务内做以下操作 a. 订单状态更新为已支付 b. 生成支付流水记录 c. 卡密状态从LOCKED更新为已售并关联订单号 d. 将卡密明文信息标记为可展示 5. 返回回调成功关键点在2如果订单已经是已支付状态再来的重复回调必须直接忽略。这是幂等控制的典型场景。3.5 订单状态机与售后边界我整理了一套订单状态机编码时所有状态迁移只允许沿着既定方向走状态含义可流向0 待支付已下单未付款1 / 41 已支付支付成功已发卡2 / 32 已完成用户确认或自动完成无3 已退款退款处理完成无4 已取消超时或用户取消无售后这块我建议毕业设计只支持支付后15分钟内可取消退款的简单规则。写一个定时任务扫描超过30分钟未支付的订单自动关闭并释放锁定的卡密。退款则直接调用模拟支付网关的回原路接口把订单状态置为已退款卡密作废。再复杂的售后期流程论文里作为展望即可。4. 数据库设计表结构和状态字段是系统的地基4.1 数据库表总览我的数据库设计一共八张核心表user用户表gift_card_template礼品卡商品表card_secret卡密池表orders订单主表order_item订单明细表payment_record支付流水表use_record卡密使用/绑定记录表operation_log管理操作日志表其中订单主表和明细表分开设计是为了将来支持一单多卡批量购买时不至于改表结构。use_record则是为了审计需要用户什么时候绑定、什么时候用了卡全程留痕。4.2 关键表SQL参考下面给出卡密表和订单表的简化建表语句基本可以直接拿去用CREATE TABLE card_secret ( id BIGINT PRIMARY KEY AUTO_INCREMENT, card_no VARCHAR(64) NOT NULL COMMENT 卡号, card_pwd VARCHAR(255) NOT NULL COMMENT 卡密密文, template_id BIGINT NOT NULL COMMENT 所属礼品卡商品, status TINYINT NOT NULL DEFAULT 0 COMMENT 0可用 1锁定 2已售 3已绑定 4作废, order_id BIGINT DEFAULT NULL COMMENT 售出订单号, bind_user_id BIGINT DEFAULT NULL COMMENT 绑定用户, expire_time DATETIME DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_card_no (card_no), KEY idx_template_status (template_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(64) NOT NULL COMMENT 业务订单号, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已完成 3已退款 4已取消, pay_time DATETIME DEFAULT NULL, cancel_time DATETIME DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里值得强调的是唯一索引和联合索引。order_no加唯一索引是订单表幂等写入的基础card_secret表的联合索引(template_id, status)能让取可用卡的查询快速命中避免全表扫描。4.3 状态字段的管理艺术用TINYINT存状态字段配合注释把字典写在SQL里这句话建议刻进脑子里。很多项目后期维护困难就是状态字段语义模糊导致的。我的习惯是给每个状态都配套一个常量类比如public class OrderStatus { public static final int WAIT_PAY 0; public static final int PAID 1; public static final int FINISHED 2; public static final int REFUNDED 3; public static final int CANCELED 4; }业务代码里只允许引用常量不写魔法数这样别人读代码、你写论文画状态图都能直接对应上。数据库的DECIMAL(10,2)用于金额字段千万不要用FLOAT或DOUBLE——二进制浮点数会在精度上给你挖坑金额差了分毫在财务上是大事。5. 并发、幂等与安全答辩时最愿意深挖的技术点5.1 库存扣减的并发控制方案对比礼品卡平台很容易出现秒杀场景——限量卡早上10点开抢。如果不做并发控制两个请求同时读到库存还剩1张结果两个订单都创建成功就超卖了。我在系统里用了两层防线应用层优先检查卡密池可用数量小于购买数量直接拒绝。数据库层用带条件的UPDATE语句实现原子扣减上面给过的UPDATE ... WHERE status0 AND id IN (...)就是核心。如果引入了Redis还可以用DECR命令做预扣库存但必须处理扣减成功但订单未支付导致缓存库存被占住的问题。毕业设计阶段用数据库乐观锁事务就够用了Redis方案可以作为加分亮点在答辩时提一句。5.2 支付幂等不能因为重复回调导致重复发卡幂等这个词是面试高频词在这个项目里也恰如其分。模拟支付网关的回调模拟了真实场景——可能会连着回调两三次。我在payment_record表里加了transaction_id唯一索引回调处理事务里的第一步就是尝试插入支付流水如果插入时唯一键冲突说明这笔回调已经处理过直接跳过后续逻辑。另外发卡操作本身也要做防重在订单状态从待支付更新为已支付时UPDATE orders SET status1 WHERE id? AND status0如果影响行数为0说明订单不是待支付状态就不允许再走发卡流程。这个设计让并发安全有了双重保障。5.3 越权与敏感数据B/S系统最典型的安全漏洞之一是水平越权——用户A通过修改URL参数里的订单ID查到了用户B的订单。我在所有查询类接口里都坚持一个原则先从token解析出当前用户ID查询时必须拼接这个用户ID作为查询条件。例如Order order orderMapper.selectByOrderNoAndUserId(orderNo, currentUserId);而不是只凭orderNo查询。这条规则对所有涉及个人数据的接口都适用。卡密属于敏感信息数据库里存的card_pwd我用AES加密只有在用户订单支付成功后的查看卡密接口里解密展示。为了减少泄露面我在设计上做了一条限制卡密明文只在支付成功后的详情页展示一次后续再查看需要输入支付密码或验证手机验证码。这个细节虽然增加了一点实现成本但答辩时讲出来会非常加分。5.4 常规安全加固清单除了上面几条Web安全里最基础的几个点也都要做到SQL注入MyBatis里尽量用#{}占位符${}只用于表名、排序字段等固定白名单不拼接任何用户输入。XSS脚本攻击富文本内容展示前做HTML转义前端Vue框架天然转义但服务端Thymeleaf模板要配置转义输出。CSRF跨站请求伪造JWT方案下把token放到Header中天然规避了Cookie自动携带的CSRF风险如果用了Session方案必须加CSRF Token校验。登录防爆破登录接口加简单的失败次数限制Redis记录IP维度连续失败5次锁定15分钟。注意安全问题不是做完了再去加固而是从写第一行代码就要带入这些意识。建议在项目的common包下写一个全局异常处理器统一捕获校验异常和业务异常避免把异常堆栈直接抛给前端。6. 实操阶段最常见的坑与排查实录6.1 MyBatis实体映射字段对不上Java规范里实体字段是驼峰命名如createTime而数据库字段是下划线命名如create_time。如果没有开启MyBatis的驼峰映射配置查询结果会是createTime为null。解决办法很简单在application.yml里加一行mybatis: configuration: map-underscore-to-camel-case: true这个配置我建议创建项目后第一时间就加上能省掉写一堆resultMap的功夫。6.2 LocalDateTime 序列化后变成一串数字Java 8的时间类型在Jackson默认序列化下会变成时间戳数组前端根本没法解析。我踩过一次坑之后直接在配置里全局指定Bean public Jackson2ObjectMapperBuilderCustomizer customizer() { return builder - builder.simpleDateFormat(yyyy-MM-dd HH:mm:ss) .serializers(new LocalDateTimeSerializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))) .deserializers(new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); }所有接口的时间字段统一为yyyy-MM-dd HH:mm:ss前后端不用再单独协商格式。6.3 前后端分离时的CORS跨域问题如果你选了Vue 后端的组合大概率会碰到跨域。后端写一个配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(http://localhost:*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowCredentials(true) .maxAge(3600); } }注意allowedOriginPatterns比allowedOrigins灵活可以带通配符allowCredentials(true)允许携带Cookie和Header信息但这时allowedOriginPatterns不能写成*。6.4 Transactional 自调用失效这是Spring事务里最隐蔽的坑。A方法调同一个类里的B方法B上面标了Transactional但事务不生效因为Spring事务通过代理对象生效自调用走的是this调用绕过代理。解决方案有三个把B方法挪到另一个Service类里、注入自己的代理对象、或者用TransactionTemplate手动管理事务。毕业设计阶段我推荐第三种——TransactionTemplate虽然代码多一点但逻辑最直白不容易出鬼。6.5 数据库时区问题服务器和数据库的时区配置不一致会出现时间差8小时的问题。连接串里明确指定时区我的习惯是在JDBC URL后追加serverTimezoneAsia/ShanghaiMySQL容器启动时也设置TZAsia/Shanghai。这样无论部署在哪里时间显示都不会漂。6.6 常见问题速查表现象可能原因处理方式接口报500且日志有LazyInitializationException实体懒加载属性在事务外被访问使用VO/DTO转换或查询时用EntityGraph显式关联用户修改头像后其他用户显示也变了静态资源浏览器缓存上传文件命名加时间戳或UUID订单支付成功后页面没有跳转回调是异步的前端轮询或WebSocket没做简化方案前端调用支付接口时轮询订单状态每2秒查一次MySQL连接一多就报Too many connections连接池配置过大或连接未释放HikariCP连接池调整maximum-pool-size: 20Redis连接超时服务器没有开放端口或密码错误检查防火墙与Redis配置连接串里配置密码7. 部署上线与扩展方向让项目真正跑在服务器上7.1 本地打包与服务器部署Spring Boot项目打成可执行jar包部署流程非常清爽。本地执行mvn clean package -DskipTests然后把target目录下的jar包传到服务器运行nohup java -jar giftcard-system.jar --spring.profiles.activeprod app.log 21 生产环境配置单独放在application-prod.yml里数据库、Redis地址都是服务器上的真实地址。服务器上再挂一个Nginx做反向代理将80端口转发到8080同时把前端静态资源交给Nginx托管。整套下来浏览器里输入域名就能访问系统了。这里要说一个容易被忽略的点发布前把后端接口的脱敏和数据校验再过一遍。尤其是注册接口和下单接口一定要做参数校验避免脏数据进库。7.2 从毕业设计到可扩展项目后续还能怎么长项目做完不等于结束。如果还有精力或者说想把这个项目继续打磨成简历上的亮点下面几条扩展路径都很有价值多商户入驻把单一平台改成平台商户模式商户自己上架礼品卡平台抽佣这样B/S架构的价值会更突出。卡券转赠用户可以把未绑定的卡送给别人需要新增gift_record表涉及权限转移业务复杂度很可观。优惠券营销系统满减券、限时折扣、会员价让价格体系从写死变成可配置。对账单与财务报表平台每天产生的支付流水太多需要一个定时任务拉账单生成每日营收汇总这个功能写论文很有料。消息通知支付成功后发送短信/邮件提醒用户卡密已到账可以对接阿里云短信服务。7.3 一点个人心得这套系统我前后踩了很多坑才稳定跑起来重来一遍的话我一定会先花一天时间把订单状态机和卡密状态机画清楚再动手写代码。很多bug根源不是代码写错而是状态流转没有理清比如已退款的订单卡密还在已售状态这种脏数据排查起来非常痛苦。如果你正准备做类似的Java Web项目我给两条最实在的建议一是宁可功能少而精也不要贪多导致每个模块都是半成品二是模拟支付回调一定多做几遍重复测试幂等逻辑在答辩现场是老师最喜欢下手拷问的点。这个系统做完之后Spring Boot、B/S架构、事务并发、接口安全这些知识点就不再是八股文里的抽象概念了——你亲手把它们串成了一条完整的线上交易链路。这份经验比任何面试题库都有说服力。
Spring Boot + B/S架构实现礼品卡销售系统：从订单到卡密全链路实战
毕业设计选题选礼品卡销售系统这个题其实挺有讲究。表面上它就是一个商城但你仔细拆开看里面既有商品管理、订单流转、库存控制这些电商通用能力又有卡密生成、兑换绑定、支付回调这类礼品卡特有的业务逻辑。用Java技术栈落地一个基于B/S架构、Spring Boot做后端的电子礼品卡在线交易平台刚好把Java Web开发里最常考、最常用的知识点都串起来了——从Spring Boot工程搭建到MyBatis数据库访问从Interceptor权限控制到事务并发处理每一个环节都有得写、有得练。这套系统做完你学到的不只是一个毕业设计而是一条从前端页面到数据库落盘的完整交易链路。这篇文章我按自己的真实开发节奏来梳理先讲清楚礼品卡系统到底在解决什么业务问题、角色和流程怎么拆解再讲技术选型为什么拍板用Spring Boot B/S然后是核心模块的实现思路、数据库设计和订单状态机接着是并发、幂等、安全这些容易翻车的细节最后把实操过程中踩过的坑和部署上线的方法一并交代清楚。无论是准备毕业设计、还是想找一个能写进简历的Java Web练手项目这篇都值得你从头到尾看完。1. 需求拆解礼品卡系统到底在做什么1.1 礼品卡的业务本质与典型场景很多人一听到礼品卡销售系统下意识觉得就是一个卖卡的商城。这话对了一半但更准确的定位是礼品卡是一种预付费凭证用户掏钱买下的一定面值/权益之后在指定平台或线下门店里兑换使用。礼品卡面向的场景很典型——企业采购用于员工福利、节日发放个人买来送朋友、送家人平台自己做活动发一堆定向卡密当营销工具。正因为是预付费系统关注的核心就不再只是把商品卖出去而是卡从哪来、卖出去之后怎么发出去、用户拿到后怎么用。这就引出了礼品卡系统区别于普通电商的两个关键元素卡密池一批批预先生成的、唯一的卡号 密码或兑换码代表真实的库存。状态流转卡密从可用到已售出再到已绑定/已消费每一步都必须有记录。把这个业务逻辑想明白功能模块的边界就出来了。1.2 系统角色、核心用例与一条完整链路一个可交付的礼品卡在线交易平台至少要覆盖三类使用者角色核心操作关注点游客/注册用户浏览礼品卡、加入购物车、下单、支付、查看卡密、绑定使用流程顺畅、卡密安全、订单可查运营/管理员维护卡商品信息、批量生成卡密、查看订单、处理异常管理效率、数据准确财务/客服可与运营合并核对订单与支付记录、处理退款退卡账实相符围绕这三类角色我建议把核心用例收敛成一条完整链路而不是一上来铺一堆功能用户注册登录 → 浏览礼品卡 → 选择面值/数量 → 确认订单 → 在线支付 → 系统自动发卡 → 用户查看卡密 → 用户在线绑定或复制卡密使用这条链路跑通系统主心骨就有了。至于优惠券、多商户、转赠、发票申请都属于锦上添花的扩展项不建议在毕业设计第一阶段就做进去否则工作量会失控。1.3 功能边界怎么划先做减法再做加法规划毕业设计时常犯一个错误把目标定成做一个像京东一样的礼品卡频道。结果商城架子搭了一堆真正能演示的业务闭环反而没走通。我当时的处理方式是核心功能只保留七块——用户注册登录、商品展示、购物车、订单生成、在线支付模拟支付即可、卡密自动发放、后台管理。扩展功能如批量赠卡、卡券转赠、销售统计报表放在二期规划里在论文里作为展望写清楚就行。这样做的好处很明显开发周期可控演示时有明确的故事线答辩时你能把每一个功能为什么这么设计讲明白。2. 技术选型B/S架构和Spring Boot为什么是最优解2.1 B/S架构在这个项目里的必然性选B/SBrowser/Server而不是C/S对这个系统来说几乎没有悬念。C/S方案要求用户安装客户端礼品卡平台的用户分布广、设备环境杂让每个人都装一个桌面程序显然不现实。而B/S架构下用户只需要浏览器服务端统一部署所有业务逻辑和数据都在服务器上前端只是展示和交互层。从工程角度B/S带来的直接好处是维护成本断崖式下降。运营人员调价、上架商品、修改卡密库存改完服务端页面马上生效不存在发版到客户端这种折腾事。另外B/S天然适合用户端 管理端双入口模式——两个Web应用共用一套后端服务只是页面和权限不同代码复用率很高。2.2 Spring Boot 为什么是毕业设计的最优后端框架换成十年前这种项目大概率是用Spring MVC XML配置堆出来的光配置文件就能绕晕新手。Spring Boot把这些繁琐操作全部收进约定优于配置里内嵌Tomcat解决了外部容器配置问题起步依赖Starter让引入框架变成一行依赖自动配置让数据源、Redis、消息队列这些组件开箱即用。对于做毕业设计的同学Spring Boot还有一个隐藏优势社区生态极其庞大。你遇到的90%问题在CSDN、掘金、Stack Overflow上都有现成答案。这一点在答辩前赶工时能救命。另外从就业角度说Spring Boot已经是Java后端开发的绝对主流用这个框架做毕业设计写在简历上有说服力。你甚至可以把它当面试项目来复盘Spring IoC、AOP、事务、Spring Security、MyBatis这些高频面试点全都有实际落点。2.3 前端、数据库与中间件的实际搭配后端定了Spring Boot之后前端和存储这边我的建议是前端如果优先保证毕业设计完成度用Thymeleaf服务端渲染就够了——页面里嵌数据直接渲染不用处理跨域和前后端联调。如果想在后端之外展示更多亮点就上Vue 3 Element Plus走前后端分离后端只出JSON接口。两种方案我都试过前者省时间后者涨经验按你的时间预算选。数据库MySQL 8.0是标配InnoDB引擎、事务支持、网上资料多没理由不选。缓存/中间件可选但推荐加一个Redis。哪怕只用在防重复提交或首页缓存上也能让技术方案更有层次。身份认证JWTJSON Web Token无状态方案适合前后端分离如果模板渲染也可以直接用Session Interceptor实现。2.4 模块拆分与Package结构B/S模式下的系统分层我习惯按表现层 - 业务层 - 数据访问层来组织MVC是骨架但Package结构要再细致一点方便后期扩展com.example.giftcard ├── controller // 接口层接收参数并返回结果 ├── service // 业务逻辑层事务边界在这里 ├── mapper // MyBatis数据访问接口 ├── entity // 数据库实体映射 ├── dto // 入参对象区分前端传参格式 ├── vo // 出参视图对象控制返回给前端的数据 ├── config // 配置文件Security、WebMvc、Redis等 ├── common // 通用类统一返回体、异常处理、常量 └── utils // 工具类这里有个很容易被忽视但很重要的设计Entity实体和VO视图对象必须分开。比如用户实体里有密码字段如果直接返回给前端密码字段就暴露了。用VO来裁剪字段是数据安全的第一道关。3. 核心模块实现把交易链路一步步跑通3.1 用户认证从注册登录到权限拦截用户模块是整个系统的基础。注册时密码不能明文入库我采用BCrypt加盐哈希存储。Spring Security内置了BCryptPasswordEncoder直接注入使用即可没必要自己写哈希算法。登录成功后我选择签发JWT返回给前端。JWT的核心工具代码大致如下public String generateToken(Long userId, String username, String role) { return Jwts.builder() .setSubject(username) .claim(userId, userId) .claim(role, role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() 1000 * 60 * 60 * 24)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact(); }前端拿到token后每次请求在Header中携带Authorization: Bearer token。后端写一个Interceptor统一解析token并把当前用户信息放进ThreadLocal。这里要给一个提示JWT的密钥不能硬编码在代码里放在application.yml或环境变量中避免泄露。权限拦截上用角色区分访问范围ROLE_USER可以访问个人中心和下单接口ROLE_ADMIN额外访问后台管理接口。管理端页面单独设前缀/admin/**拦截器里对该路径做角色校验。3.2 礼品卡商品与库存设计理解库存 卡密池普通商城的库存是一个数字礼品卡系统里库存必须有载体。我的做法是商品表gift_card_template记录SKU信息卡密表card_secret里真实存着每一张卡。字段关系用大白话解释商品表里的库存数量只是方便前端展示的冗余字段真正的可售数量来自卡密表中状态为AVAILABLE的记录数。运营导入一批卡密商品库存就自动增加了。商品表建议字段id、card_name礼品卡名称face_value面值如500元sale_price实际售价可做折扣card_type卡类型如京东E卡、沃尔玛卡、通用券cover_image、descriptionstatus0下架 / 1上架卡密表建议字段id、card_no卡号、card_pwd卡密加密存储card_template_id关联商品status0可用 / 1已售 / 2已绑定 / 3已作废order_id被哪个订单卖出去expire_time过期时间3.3 订单创建从锁定库存到生成订单下单是整个系统最容易写崩的环节。我吃过的教训是先扣库存再生成订单还是先生成订单再扣库存两种顺序在不同场景下各有坑毕业设计里我推荐生成订单 同时扣减/锁定库存放在一个事务里完成。核心逻辑用伪代码描述是这样1. 校验商品状态必须上架 2. 生成唯一订单号规则日期时间 随机数 用户ID 3. 从卡密池中取出N张AVAILABLE状态的卡标记为LOCKED 4. 创建订单记录状态待支付 5. 提交事务这里必须加上数据库层面兜底。只靠程序判断库存够不够有并发风险我用了乐观锁思路UPDATE card_secret SET status 1 WHERE status 0 AND card_template_id #{templateId} AND id IN (...)受影响行数不等于请求数量时说明卡被抢走了立即回滚并提示库存不足。3.4 支付与发卡支付成功才是真扣卡订单创建后是待支付状态用户去支付。毕业设计里不建议真的接入微信/支付宝开放平台资质、回调地址、商户号太麻烦更合理的做法是做一个模拟支付网关用户点击支付后跳到模拟收银台确认支付后由后端模拟异步回调。异步回调是重头戏也是答辩时能讲出深度的点。真正的支付回调会重复发送多次所以接口必须幂等。我的实现逻辑是1. 接收回调请求校验签名 2. 根据订单号查订单判断是否已支付 3. 若已支付直接返回成功不做重复扣卡 4. 若未支付事务内做以下操作 a. 订单状态更新为已支付 b. 生成支付流水记录 c. 卡密状态从LOCKED更新为已售并关联订单号 d. 将卡密明文信息标记为可展示 5. 返回回调成功关键点在2如果订单已经是已支付状态再来的重复回调必须直接忽略。这是幂等控制的典型场景。3.5 订单状态机与售后边界我整理了一套订单状态机编码时所有状态迁移只允许沿着既定方向走状态含义可流向0 待支付已下单未付款1 / 41 已支付支付成功已发卡2 / 32 已完成用户确认或自动完成无3 已退款退款处理完成无4 已取消超时或用户取消无售后这块我建议毕业设计只支持支付后15分钟内可取消退款的简单规则。写一个定时任务扫描超过30分钟未支付的订单自动关闭并释放锁定的卡密。退款则直接调用模拟支付网关的回原路接口把订单状态置为已退款卡密作废。再复杂的售后期流程论文里作为展望即可。4. 数据库设计表结构和状态字段是系统的地基4.1 数据库表总览我的数据库设计一共八张核心表user用户表gift_card_template礼品卡商品表card_secret卡密池表orders订单主表order_item订单明细表payment_record支付流水表use_record卡密使用/绑定记录表operation_log管理操作日志表其中订单主表和明细表分开设计是为了将来支持一单多卡批量购买时不至于改表结构。use_record则是为了审计需要用户什么时候绑定、什么时候用了卡全程留痕。4.2 关键表SQL参考下面给出卡密表和订单表的简化建表语句基本可以直接拿去用CREATE TABLE card_secret ( id BIGINT PRIMARY KEY AUTO_INCREMENT, card_no VARCHAR(64) NOT NULL COMMENT 卡号, card_pwd VARCHAR(255) NOT NULL COMMENT 卡密密文, template_id BIGINT NOT NULL COMMENT 所属礼品卡商品, status TINYINT NOT NULL DEFAULT 0 COMMENT 0可用 1锁定 2已售 3已绑定 4作废, order_id BIGINT DEFAULT NULL COMMENT 售出订单号, bind_user_id BIGINT DEFAULT NULL COMMENT 绑定用户, expire_time DATETIME DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_card_no (card_no), KEY idx_template_status (template_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(64) NOT NULL COMMENT 业务订单号, user_id BIGINT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已完成 3已退款 4已取消, pay_time DATETIME DEFAULT NULL, cancel_time DATETIME DEFAULT NULL, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里值得强调的是唯一索引和联合索引。order_no加唯一索引是订单表幂等写入的基础card_secret表的联合索引(template_id, status)能让取可用卡的查询快速命中避免全表扫描。4.3 状态字段的管理艺术用TINYINT存状态字段配合注释把字典写在SQL里这句话建议刻进脑子里。很多项目后期维护困难就是状态字段语义模糊导致的。我的习惯是给每个状态都配套一个常量类比如public class OrderStatus { public static final int WAIT_PAY 0; public static final int PAID 1; public static final int FINISHED 2; public static final int REFUNDED 3; public static final int CANCELED 4; }业务代码里只允许引用常量不写魔法数这样别人读代码、你写论文画状态图都能直接对应上。数据库的DECIMAL(10,2)用于金额字段千万不要用FLOAT或DOUBLE——二进制浮点数会在精度上给你挖坑金额差了分毫在财务上是大事。5. 并发、幂等与安全答辩时最愿意深挖的技术点5.1 库存扣减的并发控制方案对比礼品卡平台很容易出现秒杀场景——限量卡早上10点开抢。如果不做并发控制两个请求同时读到库存还剩1张结果两个订单都创建成功就超卖了。我在系统里用了两层防线应用层优先检查卡密池可用数量小于购买数量直接拒绝。数据库层用带条件的UPDATE语句实现原子扣减上面给过的UPDATE ... WHERE status0 AND id IN (...)就是核心。如果引入了Redis还可以用DECR命令做预扣库存但必须处理扣减成功但订单未支付导致缓存库存被占住的问题。毕业设计阶段用数据库乐观锁事务就够用了Redis方案可以作为加分亮点在答辩时提一句。5.2 支付幂等不能因为重复回调导致重复发卡幂等这个词是面试高频词在这个项目里也恰如其分。模拟支付网关的回调模拟了真实场景——可能会连着回调两三次。我在payment_record表里加了transaction_id唯一索引回调处理事务里的第一步就是尝试插入支付流水如果插入时唯一键冲突说明这笔回调已经处理过直接跳过后续逻辑。另外发卡操作本身也要做防重在订单状态从待支付更新为已支付时UPDATE orders SET status1 WHERE id? AND status0如果影响行数为0说明订单不是待支付状态就不允许再走发卡流程。这个设计让并发安全有了双重保障。5.3 越权与敏感数据B/S系统最典型的安全漏洞之一是水平越权——用户A通过修改URL参数里的订单ID查到了用户B的订单。我在所有查询类接口里都坚持一个原则先从token解析出当前用户ID查询时必须拼接这个用户ID作为查询条件。例如Order order orderMapper.selectByOrderNoAndUserId(orderNo, currentUserId);而不是只凭orderNo查询。这条规则对所有涉及个人数据的接口都适用。卡密属于敏感信息数据库里存的card_pwd我用AES加密只有在用户订单支付成功后的查看卡密接口里解密展示。为了减少泄露面我在设计上做了一条限制卡密明文只在支付成功后的详情页展示一次后续再查看需要输入支付密码或验证手机验证码。这个细节虽然增加了一点实现成本但答辩时讲出来会非常加分。5.4 常规安全加固清单除了上面几条Web安全里最基础的几个点也都要做到SQL注入MyBatis里尽量用#{}占位符${}只用于表名、排序字段等固定白名单不拼接任何用户输入。XSS脚本攻击富文本内容展示前做HTML转义前端Vue框架天然转义但服务端Thymeleaf模板要配置转义输出。CSRF跨站请求伪造JWT方案下把token放到Header中天然规避了Cookie自动携带的CSRF风险如果用了Session方案必须加CSRF Token校验。登录防爆破登录接口加简单的失败次数限制Redis记录IP维度连续失败5次锁定15分钟。注意安全问题不是做完了再去加固而是从写第一行代码就要带入这些意识。建议在项目的common包下写一个全局异常处理器统一捕获校验异常和业务异常避免把异常堆栈直接抛给前端。6. 实操阶段最常见的坑与排查实录6.1 MyBatis实体映射字段对不上Java规范里实体字段是驼峰命名如createTime而数据库字段是下划线命名如create_time。如果没有开启MyBatis的驼峰映射配置查询结果会是createTime为null。解决办法很简单在application.yml里加一行mybatis: configuration: map-underscore-to-camel-case: true这个配置我建议创建项目后第一时间就加上能省掉写一堆resultMap的功夫。6.2 LocalDateTime 序列化后变成一串数字Java 8的时间类型在Jackson默认序列化下会变成时间戳数组前端根本没法解析。我踩过一次坑之后直接在配置里全局指定Bean public Jackson2ObjectMapperBuilderCustomizer customizer() { return builder - builder.simpleDateFormat(yyyy-MM-dd HH:mm:ss) .serializers(new LocalDateTimeSerializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))) .deserializers(new LocalDateTimeDeserializer(DateTimeFormatter.ofPattern(yyyy-MM-dd HH:mm:ss))); }所有接口的时间字段统一为yyyy-MM-dd HH:mm:ss前后端不用再单独协商格式。6.3 前后端分离时的CORS跨域问题如果你选了Vue 后端的组合大概率会碰到跨域。后端写一个配置类Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(http://localhost:*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowCredentials(true) .maxAge(3600); } }注意allowedOriginPatterns比allowedOrigins灵活可以带通配符allowCredentials(true)允许携带Cookie和Header信息但这时allowedOriginPatterns不能写成*。6.4 Transactional 自调用失效这是Spring事务里最隐蔽的坑。A方法调同一个类里的B方法B上面标了Transactional但事务不生效因为Spring事务通过代理对象生效自调用走的是this调用绕过代理。解决方案有三个把B方法挪到另一个Service类里、注入自己的代理对象、或者用TransactionTemplate手动管理事务。毕业设计阶段我推荐第三种——TransactionTemplate虽然代码多一点但逻辑最直白不容易出鬼。6.5 数据库时区问题服务器和数据库的时区配置不一致会出现时间差8小时的问题。连接串里明确指定时区我的习惯是在JDBC URL后追加serverTimezoneAsia/ShanghaiMySQL容器启动时也设置TZAsia/Shanghai。这样无论部署在哪里时间显示都不会漂。6.6 常见问题速查表现象可能原因处理方式接口报500且日志有LazyInitializationException实体懒加载属性在事务外被访问使用VO/DTO转换或查询时用EntityGraph显式关联用户修改头像后其他用户显示也变了静态资源浏览器缓存上传文件命名加时间戳或UUID订单支付成功后页面没有跳转回调是异步的前端轮询或WebSocket没做简化方案前端调用支付接口时轮询订单状态每2秒查一次MySQL连接一多就报Too many connections连接池配置过大或连接未释放HikariCP连接池调整maximum-pool-size: 20Redis连接超时服务器没有开放端口或密码错误检查防火墙与Redis配置连接串里配置密码7. 部署上线与扩展方向让项目真正跑在服务器上7.1 本地打包与服务器部署Spring Boot项目打成可执行jar包部署流程非常清爽。本地执行mvn clean package -DskipTests然后把target目录下的jar包传到服务器运行nohup java -jar giftcard-system.jar --spring.profiles.activeprod app.log 21 生产环境配置单独放在application-prod.yml里数据库、Redis地址都是服务器上的真实地址。服务器上再挂一个Nginx做反向代理将80端口转发到8080同时把前端静态资源交给Nginx托管。整套下来浏览器里输入域名就能访问系统了。这里要说一个容易被忽略的点发布前把后端接口的脱敏和数据校验再过一遍。尤其是注册接口和下单接口一定要做参数校验避免脏数据进库。7.2 从毕业设计到可扩展项目后续还能怎么长项目做完不等于结束。如果还有精力或者说想把这个项目继续打磨成简历上的亮点下面几条扩展路径都很有价值多商户入驻把单一平台改成平台商户模式商户自己上架礼品卡平台抽佣这样B/S架构的价值会更突出。卡券转赠用户可以把未绑定的卡送给别人需要新增gift_record表涉及权限转移业务复杂度很可观。优惠券营销系统满减券、限时折扣、会员价让价格体系从写死变成可配置。对账单与财务报表平台每天产生的支付流水太多需要一个定时任务拉账单生成每日营收汇总这个功能写论文很有料。消息通知支付成功后发送短信/邮件提醒用户卡密已到账可以对接阿里云短信服务。7.3 一点个人心得这套系统我前后踩了很多坑才稳定跑起来重来一遍的话我一定会先花一天时间把订单状态机和卡密状态机画清楚再动手写代码。很多bug根源不是代码写错而是状态流转没有理清比如已退款的订单卡密还在已售状态这种脏数据排查起来非常痛苦。如果你正准备做类似的Java Web项目我给两条最实在的建议一是宁可功能少而精也不要贪多导致每个模块都是半成品二是模拟支付回调一定多做几遍重复测试幂等逻辑在答辩现场是老师最喜欢下手拷问的点。这个系统做完之后Spring Boot、B/S架构、事务并发、接口安全这些知识点就不再是八股文里的抽象概念了——你亲手把它们串成了一条完整的线上交易链路。这份经验比任何面试题库都有说服力。
