JSP+Servlet+MySQL游戏购买网站：订单事务、库存防超卖与激活码设计

简介面向Java Web入门、课程设计与毕业设计参考场景的游戏购买网站完整项目适合具备基础语法、希望打通页面到数据库完整链路的学习者围绕商品浏览、购物车、下单与后台运营等典型电商流程帮助读者理解JSPServletDAOMySQL的分层协作方式并可作为同类商城题目的改造基础。压缩包共246个文件约14.85MB包含55个Java源文件、20个JSP页面、55个编译类、9个依赖JAR以及SQL脚本、CSS/JS、图片和XML配置等基本覆盖前端页面、后端控制、数据访问与数据库初始化所需内容。已有99人学习适合需要一套可运行、结构清晰的Java Web案例来对照练习和二次开发。资源内置管理员与普通用户两类角色后台可进行订单、客户、游戏和类目管理前台可完成登录、选购、购物车、提交订单与订单查询配套admin/admin、user1/123456演示账号便于快速梳理业务闭环与权限划分。1. 一套游戏购买网站设计卡住人的往往不是页面某同学接了个毕业设计课题题目是基于 jspservletmysql 的游戏购买网站他一开始以为难点在首页轮播和商品详情页好不好看。真做起来才发现页面两天就能搭出个样子卡住他的是三件事用户付了钱没拿到激活码、两个人同时抢最后一份库存、后台管理员能随手改价把钱改丢。这套 java mysql 游戏购买 的组合之所以年年有人选是因为它把「请求进来—业务处理—数据落库」这条链路完整摊在你面前没有框架替你兜底写错了立刻体现在数据上。下面按一份能直接交出去的方案讲需求怎么划边界、8 张表怎么落、下单事务怎么写、验收那天怎么演示。2. 需求拆解与技术选型为什么这套组合反而最稳动手写代码之前先把范围固定下来这一步决定后面三个月的返工量。游戏购买网站听起来简单实际牵扯商品、库存、订单、激活码、权限五摊子事每一摊都能无限扩写。多数人翻车不是因为技术难是因为在开题阶段没有明确划定功能范围做到一半发现要加退款、要加优惠券、要加评论数据库直接推翻重来。2.1 三类角色与用例边界角色划分不需要多三个足够撑起一份完整的方案。游客只读浏览首页、按分类筛、搜索游戏名、看详情页的图文和价格能看到的库存只显示「有货/无货」不给具体数字。登录用户可以加购物车、下单、模拟支付、查看自己的订单列表和订单里的激活码。管理员是运营侧管分类、管游戏上下架、补库存、查订单、处理退款申请、封禁异常账号。边界比功能更重要这也是答辩时最容易被追问的地方。真实支付不接用「模拟支付」按钮把订单状态从待支付改到已支付答辩时主动说明这是范围控制比被问出来强。游戏本体不做下载分发卖的是激活码用户拿到码自己去对应平台兑换这样既贴合真实业务又避开了文件存储的大坑。推荐算法、评论社区、优惠券体系一律不做理由写进文档与核心交易链路无关。提示开题文档里专门写一小节「本期不做」比写十页功能列表更能体现工程判断力。用例边界定清楚之后表结构和接口数量基本就确定了用户表、管理员表、分类表、游戏表、激活码表、购物车表、订单表、订单明细表八张表刚好覆盖全部用例不多不少。2.2 技术栈选型与版本组合这套方案的技术选型核心原则是「每一层都能在答辩时讲清原理」。用 Spring 当然省事但 IOC 容器怎么扫描、事务代理怎么织入讲不透反而扣分。手写 Servlet 至少能说清 init 到 destroy 的生命周期DAO 层手写 JDBC 至少能说清 PreparedStatement 怎么防注入。层次选型版本选它的理由运行环境JDK8 或 11与 Tomcat 9 兼容性最好教程资料最多Web 容器Tomcat9.0.x命名空间仍是 javax.servlet绝大多数现成代码可直接用Web 层Servlet JSP JSTLServlet 4.0 / JSTL 1.2课设要求手写生命周期与请求转发链路清晰数据库MySQL5.7 或 8.0事务、行锁、索引都支持安装包小驱动mysql-connector-java8.0.x与 MySQL 8 匹配注意驱动类名带 cj连接池Druid1.1.x自带监控页演示连接池复用效果很直观前端Bootstrap 5 jQuery—不写原生 CSS 也能出效果省时间给后端构建Maven3.6依赖版本锁在 pom 里换机器不炸版本组合里有一个必须提前确认的点Tomcat 10 之后包名从 javax.servlet 换成了 jakarta.servlet网上抄来的代码十有八九编译不过报「程序包 javax.servlet 不存在」。要么锁死 Tomcat 9要么全量改包名两头选一个别中途换。数据库连接串里三个参数别省useUnicodetrue 和 characterEncodingutf8 决定中文不乱码serverTimezoneAsia/Shanghai 决定时间不偏移八小时这两个坑在第 5 章还会细说。前端选 Bootstrap 不是为了好看是为了让列表页、表单页、弹窗在一周内全部成型把时间留给订单和库存这两块真正有技术含量的地方。JSTL 的 c:forEach 和 c:if 足以覆盖所有页面渲染需求不需要引入模板引擎。2.3 工程结构与分层约定包结构一旦定了就别中途改否则 import 改到你怀疑人生。按职责切四个包controller 只负责收参数、调 service、转发页面service 承载业务规则和事务边界dao 只写 SQLentity 是纯数据载体一个字段对应一列不塞业务方法。util 放数据库工具、订单号生成、MD5 加密这类横切的东西。game-shop/ ├── src/main/java/com/shop/ │ ├── controller/ # Servlet/game/list、/cart/add、/order/create … │ ├── service/ # 业务规则 事务边界一个方法一个事务 │ ├── dao/ # 纯 JDBCSQL 只出现在这一层 │ ├── entity/ # User、Game、Orders、OrderItem … │ ├── filter/ # LoginFilter、AdminFilter、EncodingFilter │ └── util/ # DBUtil、OrderNoGen、MD5Util、PageResult ├── src/main/webapp/ │ ├── WEB-INF/jsp/ # 全部 JSP 放这里禁止浏览器直接访问 │ ├── static/ # bootstrap、jquery、上传的封面图 │ └── WEB-INF/web.xml # Servlet 3.0 可用注解替代留作兜底 └── pom.xmlJSP 全部塞进 WEB-INF 下是个小习惯但收益很大浏览器无法直接敲 URL 访问到视图层所有请求必须经过 Servlet参数校验和权限检查就没法被绕过。连接池用静态块初始化一次全局复用不要在每次请求里 new 一个 DataSource。public final class DBUtil { private static final DataSource DS; static { DruidDataSource ds new DruidDataSource(); // 三个必带参数编码、时区、SSL少一个就等着排查乱码和时间偏移 ds.setUrl(jdbc:mysql://localhost:3306/game_shop ?useUnicodetruecharacterEncodingutf8 serverTimezoneAsia/ShanghaiuseSSLfalse); ds.setUsername(shop); ds.setPassword(shop_2024); ds.setInitialSize(5); // 启动即建 5 条连接避免首屏卡顿 ds.setMaxActive(20); // 上限按并发估课设场景 20 足够 ds.setMaxWait(3000); // 拿不到连接最多等 3 秒超时抛异常而不是无限挂起 ds.setValidationQuery(SELECT 1); DS ds; } public static Connection getConnection() throws SQLException { return DS.getConnection(); } }maxActive 不是越大越好MySQL 默认最大连接数是 151池子开到 200 只会让数据库端报 too many connections。initialSize 设成 5 能让第一次访问不至于因为建连接而卡顿。maxWait 一定要设否则连接泄漏时请求会一直挂着不返回前端表现就是页面转圈到超时日志里什么都看不到非常难查。3. 数据库设计8 张表撑起商品、订单、库存三条主线表设计是整个方案的地基改表比改代码贵十倍。这里的主线只有三条商品从哪来分类 游戏、库存怎么算激活码、钱怎么记订单 明细。购物车是临时的用户表是支撑的这四条线交叉出来的就是全部业务。3.1 八张表的分工与关键字段先说结论game 表存商品信息和一个冗余的 stock 字段game_key 表存每一条激活码orders 只存订单头和总金额order_item 存明细快照。冗余 stock 是为了列表页不用每次 count 激活码代价是发码时必须同步扣减这个一致性在第 4 章的事务里保证。表名作用关键字段user买家账号id、username、passwordMD5、status、create_timeadmin管理员id、username、password、rolecategory游戏分类id、name、sortgame游戏商品id、name、category_id、price、stock、cover、statusgame_key激活码明细id、game_id、key_code、status、order_item_idcart购物车id、user_id、game_id、numorders订单头id、order_no、user_id、total_amount、status、create_timeorder_item订单明细id、order_id、game_id、game_name、price、num、key_codeorder_item 里的 game_name 和 price 是快照字段不是冗余设计失误。商品改价、改名、下架之后历史订单必须显示下单当时的信息否则用户翻旧订单会发现金额对不上这种投诉没法解释。同理 key_code 直接写在明细里一个明细行对应一个激活码数量大于 1 就拆成多行逻辑最简单。CREATE TABLE game ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(120) NOT NULL, category_id INT NOT NULL, price DECIMAL(10,2) NOT NULL, -- 金额一律 DECIMAL禁用 FLOAT/DOUBLE stock INT NOT NULL DEFAULT 0, cover VARCHAR(255) DEFAULT NULL, status TINYINT NOT NULL DEFAULT 1, -- 1 上架 0 下架 create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, KEY idx_cate_status (category_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE game_key ( id BIGINT PRIMARY KEY AUTO_INCREMENT, game_id INT NOT NULL, key_code VARCHAR(64) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0 未售 1 已售 order_item_id BIGINT DEFAULT NULL, UNIQUE KEY uk_key (key_code), KEY idx_game_status (game_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE orders ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, user_id INT NOT NULL, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, -- 0 待支付 1 已支付 2 已发码 3 已取消 create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, pay_time DATETIME DEFAULT NULL, UNIQUE KEY uk_order_no (order_no), KEY idx_user_time (user_id, create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, game_id INT NOT NULL, game_name VARCHAR(120) NOT NULL, -- 下单时的名称快照 price DECIMAL(10,2) NOT NULL, -- 下单时的价格快照 num INT NOT NULL, key_code VARCHAR(64) DEFAULT NULL, KEY idx_order (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字符集统一用 utf8mb4 而不是 utf8游戏名里出现生僻字或者玩家昵称带表情符号时utf8 三字节存不下会直接报错。金额字段用 DECIMAL(10,2)如果用 DOUBLE 存 19.9累加几次之后可能出现 19.899999999订单总额和明细对不上对账时非常难受。3.2 下单落库的时序与事务边界一次下单要碰四张表写 orders、写 order_item、更新 game_key 状态、扣 game.stock。这四步必须在一个事务里中途任何一步失败都要整体回滚否则会出现「订单在但没码」或者「码发了但库存没减」这种脏数据。正确的顺序是先开事务按游戏 id 从小到大排序避免多商品下单时的死锁逐个SELECT ... FOR UPDATE锁住 game 行并校验库存全部通过后再写订单头然后逐条写明细、占激活码、扣库存最后 commit。排序这一步很多人忽略两个用户同时买 A 和 B一个先 A 后 B一个先 B 后 A就会互相等锁直到超时。取消订单是反方向操作状态改为已取消把 order_item 里的 key_code 对应的 game_key 状态重置为未售、order_item_id 置空再把 stock 加回去。这一套也必须在一个事务里且要判断当前状态是否为待支付已支付的订单不能直接取消只能走退款流程。3.3 索引设计与列表查询索引只建在真正会用到的条件上。game 表按分类筛列表是最频繁的查询(category_id, status)联合索引能覆盖「某分类下所有上架游戏」orders 表用户查自己的订单(user_id, create_time)让订单列表按时间倒序走索引不用额外排序game_key 表发码时要找「某游戏第一个未售的码」(game_id, status)正好命中。key_code 上的唯一索引是数据安全网程序出错重复插入时数据库直接拦下来比事后查数据强。不要给每个字段都加索引写多读少的表加索引纯属自找麻烦而且 MySQL 选错索引时查询反而更慢。课设规模的数据量下两三张核心表各一两个索引就够了剩下的靠 SQL 写对。4. 核心模块实现登录拦截、商品分页、下单扣库存与后台状态机实现阶段最忌讳的是「一个 Servlet 干完所有事」。见过不少课程设计一个 GameServlet 里 if 判断 action 参数然后几百行代码从上写到下登录、列表、详情、加购全在里面改一个功能要读半小时。按 URL 拆 Servlet一个动作一个类虽然类多了但每个类都短得能一眼看完。4.1 登录会话与两个过滤器登录流程本身不难表单提交到 LoginServlet查库校验密码存的是 MD5比对也用 MD5成功后把 User 对象放进 HttpSession重定向回首页。真正的设计点在于「哪些路径必须登录」这个判断不应该散落在每个 Servlet 里交给过滤器统一做。WebFilter(urlPatterns {/cart/*, /order/*, /user/*}) public class LoginFilter implements Filter { Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; HttpServletResponse resp (HttpServletResponse) response; // 关键false 表示不主动创建 session避免给爬虫和游客凭空建会话 HttpSession session req.getSession(false); Object user (session null) ? null : session.getAttribute(loginUser); if (user null) { // 把原始地址带上登录后能跳回去体验差别很大 String back URLEncoder.encode(req.getRequestURI(), UTF-8); resp.sendRedirect(req.getContextPath() /login.jsp?back back); return; } chain.doFilter(request, response); // 放行请求继续走到目标 Servlet } }getSession(false) 是个容易被忽略的细节写成 getSession(true) 的话每个未登录请求都会创建一个空会话Tomcat 内存里堆一堆没人用的 session压测时表现就是内存缓慢上涨。urlPatterns 只挂需要保护的三组路径商品浏览、搜索、详情页不拦游客能正常逛。管理员侧单独一个 AdminFilter挂在/admin/*上判断 session 里的 admin 对象。两个过滤器不要合并成一个用角色分支判断职责分开后面改权限规则时不用动另一条逻辑。密码用 MD5 加固定盐就行课设层面够了答辩时主动说明 MD5 不可逆但可撞库、生产环境应换 BCrypt比假装安全更得分。4.2 商品列表的分页与条件检索分页不要用 JSP 里全查出来再截取那种写法数据一多必卡。标准做法是两条 SQL一条SELECT COUNT(*)拿总数一条带LIMIT offset, size拿当前页数据。两条 SQL 的条件必须完全一致这一点下面第 5 章会作为踩坑点展开。public PageResultGame page(Integer categoryId, String keyword, int page, int size) throws SQLException { StringBuilder where new StringBuilder( WHERE status 1); ListObject params new ArrayList(); if (categoryId ! null categoryId 0) { where.append( AND category_id ?); params.add(categoryId); } if (keyword ! null !keyword.trim().isEmpty()) { where.append( AND name LIKE ?); params.add(% keyword.trim() %); // 前后模糊注意这里走不了索引 } int total; try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(SELECT COUNT(*) FROM game where)) { bind(ps, params); try (ResultSet rs ps.executeQuery()) { rs.next(); total rs.getInt(1); } } ListGame list new ArrayList(); String sql SELECT id, name, cover, price, stock FROM game where ORDER BY id DESC LIMIT ?, ?; try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { int i bind(ps, params); // 复用同一组条件参数返回下一个占位符下标 ps.setInt(i, (page - 1) * size); // offset从 0 开始 ps.setInt(i 1, size); // size每页条数 try (ResultSet rs ps.executeQuery()) { while (rs.next()) list.add(mapRow(rs)); } } return new PageResult(list, total, page, size); }bind 方法负责把条件参数按顺序塞进 PreparedStatement 并返回下一个可用下标这样 count 和 list 两条 SQL 共用一份条件永远不会出现「总数说有 37 条、翻到第 4 页是空的」这种诡异现象。size 一般固定 12 或 20page 从 1 开始前端传非法值0、负数、超过总页数时在 Servlet 里校正到合法区间别指望数据库替你兜。搜索结果里LIKE %关键词%前后都带通配符索引失效走全表扫描数据量小的时候完全无感几万行之后能明显看到慢。课设规模不必上全文索引但答辩时被问到要能说出这个限制和优化方向这是加分项。4.3 下单与库存扣减的完整事务这是整个项目最值得写进论文的一节。核心矛盾是库存判断和库存扣减必须原子否则并发下必然超卖。做法是把校验和扣减放进同一个数据库事务用FOR UPDATE行锁把该商品的行锁住第二个请求进来会阻塞等待第一个提交后它读到的就是扣减后的库存。public String createOrder(int userId, ListCartItem items) throws Exception { Connection conn null; try { conn DBUtil.getConnection(); conn.setAutoCommit(false); // 事务开始后续所有写操作同生共死 // 1. 按 gameId 升序防止两个用户交叉下单造成死锁 items.sort(Comparator.comparingInt(CartItem::getGameId)); BigDecimal total BigDecimal.ZERO; for (CartItem it : items) { // 2. 行锁这条 SELECT 会锁住该游戏行直到事务结束 Game g gameDao.lockById(conn, it.getGameId()); if (g null || g.getStatus() ! 1) { throw new BizException(商品已下架 it.getGameId()); } if (g.getStock() it.getNum()) { throw new BizException(《 g.getName() 》库存不足仅剩 g.getStock() 份); } it.setPrice(g.getPrice()); // 价格以数据库为准不信前端传的 total total.add(g.getPrice().multiply(BigDecimal.valueOf(it.getNum()))); } // 3. 写订单头状态 0 待支付 String orderNo OrderNoGen.next(); // 时间戳 用户尾号 4 位随机 long orderId orderDao.insert(conn, orderNo, userId, total, 0); // 4. 写明细、占激活码、扣库存三步绑在一起 for (CartItem it : items) { for (int n 0; n it.getNum(); n) { String key gameKeyDao.takeOne(conn, it.getGameId()); // 取一条未售码并置为已占 if (key null) throw new BizException(激活码库存异常请联系客服); orderItemDao.insert(conn, orderId, it, key); } gameDao.decreaseStock(conn, it.getGameId(), it.getNum()); // UPDATE game SET stock stock - ? } conn.commit(); // 全部成功才落盘 return orderNo; } catch (Exception e) { if (conn ! null) conn.rollback(); // 任何一步失败订单、明细、码、库存全部还原 throw e; } finally { if (conn ! null) { conn.setAutoCommit(true); // 还回连接池前必须恢复默认值 conn.close(); } } }几个细节值得单独说。价格必须从数据库重新读不能信任前端表单传来的 price否则改一下请求参数就能一块钱买走游戏。items 排序是为了死锁预防这点在前面已经解释过。finally 里把 autoCommit 恢复成 true 是纪律连接池复用连接时如果带着 autoCommitfalse 状态回去下一个借到它的请求会莫名其妙地不提交这个 bug 排查起来极其痛苦。支付环节做模拟用户点「去支付」PayServlet 把 orders.status 从 0 改成 1同时写 pay_time紧接着调发码逻辑把 order_item 里的 key_code 展示到订单详情页orders.status 再推进到 2。发码确认可以合并到支付动作里一次事务完成也可以拆成两步演示状态流转看答辩时想强调什么。4.4 后台管理的订单状态机订单状态不能随便改必须定义成有限状态机每个流转写清楚触发条件和允许的源状态。这张表建议直接放进论文评审看的是你有没有想清楚业务规则。当前状态允许流转到触发动作校验条件0 待支付1 已支付用户支付订单属于当前用户、未超时0 待支付3 已取消用户取消 / 30 分钟超时无1 已支付2 已发码系统发码 / 管理员手动激活码分配成功1 已支付3 已取消管理员退款需填写退款原因2 已发码—终态激活码已交付不可回退后台的状态修改接口只暴露「取消」和「发码」两个动作不提供「直接改成任意状态」的下拉框。数据库层面在 update 语句里带上源状态条件UPDATE orders SET status 2 WHERE id ? AND status 1返回影响行数为 0 就说明状态已经被别处改过直接提示失败。这种乐观校验成本几乎为零却能挡住重复点击和并发操作导致的脏数据。后台商品管理还要注意一点删商品用逻辑删除status 置 0而不是物理 DELETE。订单明细里存的是 game_id 快照商品行真删了历史订单点进去查不到商品信息页面直接报空指针。这个坑在演示环节特别容易暴露因为演示时为了展示「下架」效果往往现场删一个。5. 避坑清单这个项目里最容易翻车的五个点下面这五条基本覆盖了同类项目 80% 的求助帖。每一条我都按「现象—原因—解决」写遇到问题可以直接对号入座。5.1 中文乱码表单提交全是问号现象JSP 页面输入中文游戏名保存到数据库变成???或者列表页显示成乱码方块。原因是字符集在三个环节各有一套请求体编码、响应体编码、数据库连接编码任何一环没设对都会乱。解决办法是三层一起治EncodingFilter 里无条件设置request.setCharacterEncoding(UTF-8)和response.setContentType(text/html;charsetUTF-8)且必须在所有 Servlet 之前执行JDBC URL 带上useUnicodetruecharacterEncodingutf8建库建表统一CHARSETutf8mb4。还有一个容易漏的点GET 请求的参数编码由 Tomcat 的 server.xml 决定光设 request 的编码不管用需要在 Connector 上加URIEncodingUTF-8。如果发现 POST 正常、GET 乱码问题一定在这里。另外过滤器里的 setCharacterEncoding 必须写在 chain.doFilter 之前写在后面等于没写。5.2 连接泄漏跑一会儿就卡死日志里什么都没有现象本地测试正常连续点几十次之后页面开始转圈最后抛GetConnectionTimeoutException重启 Tomcat 又好了。原因基本都是 Connection 用完没关或者中途抛异常跳过了 close。JDBC 的 Connection 是稀缺资源池子里就 20 条泄漏 20 次就彻底堵死。解决办法是全部改成 try-with-resources让编译器保证关闭// 正确写法无论是否抛异常conn / ps / rs 都会按逆序关闭 try (Connection conn DBUtil.getConnection(); PreparedStatement ps conn.prepareStatement(sql)) { ps.setInt(1, gameId); try (ResultSet rs ps.executeQuery()) { while (rs.next()) { /* 处理结果 */ } } }注意 try-with-resources 只对实现了 AutoCloseable 的对象生效Connection、PreparedStatement、ResultSet 都支持。还有一种隐蔽泄漏是忘记归还连接池里的连接时恢复 autoCommit这个在第 4 章提过。开着 Druid 的监控页/druid/index.html能实时看到活跃连接数和等待线程数答辩演示时打开这个页面比嘴上说「用了连接池」有说服力得多。5.3 重复提交与超卖一次点击生成两笔订单现象用户手快连点两下「提交订单」订单列表里出现两条一模一样的记录库存被扣了两次或者两个人同时买最后一份都下单成功激活码只有一条第二个人拿不到码。原因有两个层面前端没有防重复提交后端没有对库存加锁。解决分三步走。前端在提交按钮上绑定一次性的 disable点击后立即置灰。后端用订单号的唯一索引兜底同一用户短时间内重复提交相同商品生成相同 order_no 时数据库直接拒绝捕获DuplicateKeyException后提示「订单已提交请勿重复操作」。库存层面用 4.3 里的SELECT ... FOR UPDATE行锁保证判断和扣减之间没有窗口期。这三道防线里唯一索引是最可靠的一道因为它不依赖应用层逻辑。但要注意 order_no 生成规则必须能区分正常业务用「时间戳到秒 用户 id 后两位 4 位随机」已经足够两个用户在同一秒下单也不会撞。5.4 金额用错类型订单总额和明细对不上现象购物车里 19.9 29.9 9.9页面显示 59.7订单详情里三个明细加起来是 59.699999999。原因是用 double 或 float 存金额二进制浮点表示不了 0.1 这类十进制小数。解决办法是数据库用 DECIMAL(10,2)Java 侧统一用 BigDecimal且必须用字符串构造new BigDecimal(19.90)而不是new BigDecimal(19.90)后者会把 double 的误差原样带进来。BigDecimal 做除法时记得指定精度和舍入模式divide(x, 2, RoundingMode.HALF_UP)不然遇到除不尽的小数直接抛 ArithmeticException。金额的加减乘全部走 BigDecimal 的方法别用运算符。5.5 分页的总数和列表用了两套条件现象搜索某个关键词页面显示「共 37 条」但翻到第 3 页只有 2 条第 4 页是空白。原因是 count 查询和 list 查询分别拼了 WHERE 条件某次改动只改了一边。解决办法是把条件拼装抽成一个方法返回 where 子句和参数列表两条 SQL 共用参数绑定也用同一个 bind 方法按序填充。另外 LIMIT 的 offset 必须是(page-1)*size写成page*size会永远跳过第一页这个 off-by-one 错误调试时很容易看走眼因为「数据能出来」所以不觉得有问题。还有一个细节查询结果为空时前端翻页组件要隐藏或者禁用别让用户点到第 100 页还是空白体验和答辩观感都不好。6. 验收与答辩一份能照着跑的演示脚本到了这一步代码写没写完其实已经定了能不能拿分主要看怎么演示。我一般会提前写一份 8 分钟的演示脚本每个步骤配一句解说卡壳就跳过绝不现场调 bug。脚本的核心逻辑是「先展示主链路再展示防错能力」前者证明功能完整后者证明你想过边界。第一步游客浏览首页按分类筛一次搜一个关键词说明分页和检索的实现方式。第二步注册一个新账号加两个游戏进购物车把其中一个数量改成 3展示金额随数量实时重算。第三步提交订单故意点两次提交按钮展示「请勿重复操作」提示然后打开订单详情这一下把防重复提交讲完了。第四步模拟支付页面刷新出 4 个激活码逐条对应订单明细。第五步切到后台把其中一个商品的库存改成 0回前台用另一个账号下单展示「库存不足仅剩 0 份」。第六步打开 Druid 监控页展示连接池活跃数在几个并发请求下的变化。答辩提问集中在六个方向提前把答案写成一句话版本背下来高频问题回答要点为什么不用 Spring课设目标是掌握请求链路和 JDBC 底层手写能完整说清 Servlet 生命周期与事务边界超卖怎么解决行锁 事务校验和扣减在同一事务内SELECT ... FOR UPDATE阻塞并发请求密码为什么不加密存实际存的是加盐 MD5说明 MD5 可被彩虹表攻击生产应换 BCrypt事务在哪一层控制Service 层一个业务方法一个事务DAO 只接收外部传入的 Connection激活码发完了怎么办支付前预占取不到码直接回滚并提示不会出现钱付了没码表为什么这么设计商品、库存、订单三条主线快照字段保证历史订单不受改价影响有一次我把演示脚本里的顺序写反了先演示后台改库存再去前台下单结果前后两个浏览器 session 没切换干净台上看到的库存是缓存里的旧值当场愣了几秒才反应过来。从那以后我每次上台前都强制走一遍「关全部标签页、重开无痕窗口、按脚本顺序点一遍」的流程宁可多花五分钟也不在演示环节赌运气。这套方案里的表结构、事务代码和演示脚本是一个整体缺哪块都跑不通需要完整工程文件的话可以按标题去找对应的下载包。希望帮到你。本文还有配套的精品资源点击获取