简介一份面向JavaWeb学习者的蛋糕商城项目源码覆盖客户管理、商品管理、订单管理三条主线。普通用户可注册、登录、修改资料管理员能进行客户增删改与密码重置商品侧实现了基于cookie-json的购物车、商品分类检索、图片上传及条幅/热销/新品推荐订单侧提供用户下单和管理员查询删除的完整闭环。包内共225个文件包括52个java源文件、52个class编译产物、23个jsp页面、16个css样式及jar依赖、jpg静态素材和sql数据库脚本整体10.97MB目录结构清晰。已有6784人学习下载适合作为课程设计或毕业设计参考可直接导入并运行用于熟悉Servlet、JSP、Cookie/JSON交互及购物车、订单等典型业务场景。1. JavaWeb蛋糕商城到底练什么一个把Servlet、JSP和MySQL串成闭环的完整案例搜“JavaWeb蛋糕商城”的人八成都不是真想买蛋糕而是要找一个能把Servlet、JSP、MySQL、Tomcat串成完整闭环的练手项目。跟着黑马JavaWeb笔记学完每个知识点都懂但合上笔记要自己交一个javaweb项目完整案例mysql版本的课设很多人卡在连IDEA运行JavaWeb项目配置里的Artifact都没搞明白。蛋糕商城这个题目恰好踩在“完整”和“可完成”的交界处注册登录、分类展示、购物车、订单、后台管理一环扣一环覆盖JavaWeb核心考点又不会逼你提前碰Spring全家桶。这篇不按课件顺序写按我实际带过的做法从技术栈、数据库到部署坑位挨个讲完适合准备课设或实训作业的读者照着重现一遍。2. 蛋糕商城技术选型与IDEA运行JavaWeb项目配置JDK、Tomcat、MySQL版本怎么配2.1 技术栈怎么定Servlet/JSP还是SpringMVC别一上来就上全家桶很多第一次做JavaWeb完整课设的同学上来就纠结要不要直接用SpringBoot毕竟现在公司里没人手写Servlet了。但如果你还处于培训或实训阶段答案应该反过来看课设和实训练的是JavaWeb底层链路不是让你把SpringBoot的自动配置抄一遍。我一般会建议选Servlet JSP JDBC MySQL这套纯JavaWeb组合。先给一个参考的版本搭配这是我实际跑通多次的组组件推荐版本说明JDK1.8Java 8与Tomcat 8.5/9.0完全兼容教程代码最多Tomcat8.5或9.09.0对应Servlet 4.0仍是javax命名空间MySQL5.7或8.0都可8.0需要额外三个连接参数见5.5Servlet API3.1/4.0由Tomcat内置项目里不需要单独引包第一蛋糕商城的业务量级完全不需要框架兜底。用户注册、商品列表、购物车、订单这些接口用HttpServlet写每个不过几十行SpringMVC在这里的收益主要是路径映射和参数绑定但这些收益在你学习时会掩盖Servlet容器的运行机制。第二实训平台判分通常是黑盒检测的是功能有没有实现用不用框架不加分。第三纯Servlet项目依赖少部署时一个Tomcat就解决不会出现Spring版本冲突这种跟业务无关的麻烦。如果一定想留一点现代感可以在JSP里用JSTL和EL表达式这个组合在黑马JavaWeb笔记数据里也是常规操作不算超纲。JDBC部分我不建议上MyBatis原因也一样MyBatis的Mapper代理机制会把你对Connection、PreparedStatement、ResultSet的掌控感全部拿走而这些恰恰是javaweb项目完整案例里最值得手写一遍的部分。版本选择上唯一要注意的是Tomcat 10以上。如果你手滑装了Tomcat 10那走的是jakarta.servlet命名空间之前所有教程代码的import javax.servlet都要改成jakarta.servlet改起来耗时不说网上搜到的代码还大多没迁移过。对于新手来说这是灾难级的翻车点。除非你要交的实训明确要求Tomcat 10否则不要为“新版”去碰这个坑。2.2 IDEA里跑通JavaWeb项目的最小配置Tomcat与Artifact的四个关键参数IDEA里的JavaWeb项目跟普通Java项目的最大区别在于你写的代码最终要被打成WAR或war exploded目录丢给Tomcat执行而IDEA帮忙做了这一步。很多人的IDEA运行JavaWeb项目配置流程是点一下Run按钮浏览器弹出404然后就没有然后了。这里我把最容易错的四个参数单独摘出来。第一个是Application Server。在Run/Debug Configurations里新建Tomcat Server Local这个下拉框选择你本地解压的Tomcat目录不是IDEA自带的那个也不是Maven仓库里的那个。选错之后Tomcat会直接起不来报Error configuring application listener的错。第二个是HTTP port。Tomcat默认8080如果你本机有别的服务占了8080IDEA不会主动提示只会报Address already in use。这种时候改到8081或9090都行但注意改完之后浏览器访问的地址也要跟着变否则你会花十分钟怀疑代码。第三个是Artifact。这个最玄学。要在Deployment标签页里点加号选择Artifact...把项目名字带_war_exploded的那个加进去Application context写成/cake。这里记住war和war exploded的区别在于前者是压缩包后者是解压后的目录。IDEA调试必须选exploded否则每改一次JSP都要重新打包改前端页面会改到怀疑人生。第四个是Update resources。在Deployment页面或Server标签里找到On frame deactivation和On Update action两个下拉框都设成Update resources。这样你改一个JSP或CSS切回IDEA窗口时热更新直接生效不用重启Tomcat。这个配置能帮你节约大量时间。把这四项设完之后正常启动会在控制台看到一行信息Deployment of web application archive has finished in ... ms然后浏览器访问http://localhost:8080/cake/index.jsp就能看到页面。如果没看到先去把第5章的404清单过一遍大概率能解决。3. 蛋糕商城的MySQL数据库设计六张表怎么拆、订单状态怎么流转3.1 用户、分类、商品三张基础表字段设计决定后面少写多少JOIN蛋糕商城的表结构我先给结论一共六张表——t_user、t_category、t_cake、t_order、t_order_item、t_cart_item。购物车这张表在纯Servlet课设里是可选的因为很多方案直接把购物车对象扔Session里但我建议两套都做为什么后面单独说。先看最基础的三张表DDLCREATE DATABASE cake_shop DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci; USE cake_shop; CREATE TABLE t_user ( id INT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(32) NOT NULL UNIQUE, password VARCHAR(64) NOT NULL, nickname VARCHAR(32), phone VARCHAR(20), created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_category ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(32) NOT NULL, sort INT DEFAULT 0 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_cake ( id INT PRIMARY KEY AUTO_INCREMENT, category_id INT NOT NULL, name VARCHAR(64) NOT NULL, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, image VARCHAR(255), detail TEXT, status TINYINT DEFAULT 1, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_cake_category FOREIGN KEY (category_id) REFERENCES t_category(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里有三处是我带课设时反复强调的。第一库名表名统一用小写加下划线。MySQL在Linux下对表名大小写敏感Windows不敏感你本地写Cake开发好好的部署到服务器上全报Table doesnt exist。第二price字段必须用DECIMAL(10,2)不可以用DOUBLE。float和double在MySQL里是近似值0.1加0.2会得到0.30000000000000004订单金额出现这种误差验收时会被直接扣分。第三category_id外键一定要建。虽然不建外键功能上也跑得通但评分标准里通常会看关系完整性而且建外键能作为一种免费的逻辑保护删除分类时如果已有商品引用MySQL会拒绝执行。3.2 订单与购物车为什么订单明细必须单独建表状态机怎么设计接下来是订单相关的三张表。表名我建议用t_order而不是order因为ORDER在SQL里是排序关键字如果你直接叫order每次查询都得加反引号转义麻烦且容易漏。CREATE TABLE t_order ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, order_no VARCHAR(32) NOT NULL UNIQUE, total_amount DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 0, receiver_name VARCHAR(32) NOT NULL, receiver_phone VARCHAR(20) NOT NULL, receiver_address VARCHAR(128) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, CONSTRAINT fk_order_user FOREIGN KEY (user_id) REFERENCES t_user(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_order_item ( id INT PRIMARY KEY AUTO_INCREMENT, order_id INT NOT NULL, cake_id INT NOT NULL, cake_name VARCHAR(64) NOT NULL, price DECIMAL(10,2) NOT NULL, quantity INT NOT NULL, subtotal DECIMAL(10,2) NOT NULL, CONSTRAINT fk_order_item_order FOREIGN KEY (order_id) REFERENCES t_order(id), CONSTRAINT fk_order_item_cake FOREIGN KEY (cake_id) REFERENCES t_cake(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE t_cart_item ( id INT PRIMARY KEY AUTO_INCREMENT, user_id INT NOT NULL, cake_id INT NOT NULL, quantity INT NOT NULL DEFAULT 1, CONSTRAINT fk_cart_item_user FOREIGN KEY (user_id) REFERENCES t_user(id), CONSTRAINT fk_cart_item_cake FOREIGN KEY (cake_id) REFERENCES t_cake(id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单状态我这里用TINYINT数字表示0待支付1已支付2已发货3已完成4已取消。不建议用字符串因为字符串状态在代码里要写一堆equals(待支付)容易拼错还不容易发现。用数字状态机代码里只需要一个switch或if-else比较int值。订单明细单独建表的原因很简单一张订单可能包含多个商品如果把商品信息和订单存在一行下单两个蛋糕时数据要拆成两行order_no和receiver都要重复存储查询时会得到两条记录显示逻辑变得非常别扭。拆成t_order和t_order_item之后订单头存一次配送信息订单项存商品。这里最关键的细节是order_item里的cake_name和price属于冗余存储。为什么因为下单之后如果后台修改了蛋糕名称或价格历史订单不能被篡改。你去任何电商平台查几个月前的订单商品名和价格还是当时下单时的样子靠的就是这层快照。第一次做课设的人很容易只存一个cake_id查询时去JOIN蛋糕表这在展示历史订单时就是大坑。如果你打算把这个项目交到头歌这类实训平台上订单快照就是评分点里经常被扣分的位置。3.3 用一份SQL脚本把蛋糕商城的数据初始化跑起来数据库建完之后页面还是空的这时候最需要一份初始化数据不然代码调通后看到的是空白列表影响调试信心。我一般会准备一份包含分类、商品和测试账号的INSERT脚本INSERT INTO t_category (name, sort) VALUES (奶油蛋糕, 1), (慕斯蛋糕, 2), (翻糖蛋糕, 3), (cupcake, 4); INSERT INTO t_cake (category_id, name, price, stock, image, detail) VALUES (1, 草莓奶油蛋糕, 128.00, 50, /images/cake1.jpg, 新鲜草莓动物奶油6寸), (1, 芒果奶油蛋糕, 118.00, 50, /images/cake2.jpg, 大颗芒果果肉夹心), (2, 巧克力慕斯, 98.00, 30, /images/cake3.jpg, 66%黑巧克力慕斯), (3, 生日派对翻糖蛋糕, 198.00, 10, /images/cake4.jpg, 可定制主题图案); INSERT INTO t_user (username, password, nickname) VALUES (admin, 123456, 管理员), (demo, 123456, 演示用户);执行方式有两种在IDEA的Database面板新建MySQL数据源后右键运行脚本或者直接命令行执行mysql -uroot -p cake_shop.sql。跑完后执行select count(*) from t_cake;看到返回4条记录说明数据库部分已经通了。这里顺带提一个mysql连接驱动类的坑因为几乎每个做javaweb项目完整案例mysql方案的都会碰到。如果你用的是mysql-connector-java 5.x驱动类是com.mysql.jdbc.Driver如果用8.x驱动类变成com.mysql.cj.jdbc.Driver而且连接URL里必须加allowPublicKeyRetrievaltrue和serverTimezoneAsia/Shanghai否则要么报Public Key Retrieval is not allowed要么报时区错误。真因为驱动类名报ClassNotFoundException的话优先检查jar是不是放在WEB-INF/lib下面IDEA里只添加了Library而没打包进Artifact是头号原因。4. 蛋糕商城前后端串联JSP页面、Servlet控制器与Session状态管理4.1 用JSP include与EL表达式搭出页面骨架避免每个页面复制粘贴纯JSP做前端有一个最常见的坏味道系统的十个页面顶部导航和底部版权各复制十份。改一次版权信息就要打开十个文件改完还经常漏一两个。模块化的做法是拆公共片段JSP里用静态include或动态include都行对于纯静态的头部和底部静态include更直接% page contentTypetext/html;charsetUTF-8 languagejava % % taglib prefixc urihttp://java.sun.com/jsp/jstl/core % html head title蛋糕商城/title link relstylesheet href${pageContext.request.contextPath}/css/style.css /head body % include file/WEB-INF/views/common/header.jsp % div classcontainer h2蛋糕列表/h2 c:forEach varcake items${cakeList} div classcake-card img src${pageContext.request.contextPath}${cake.image} alt${cake.name} h3${cake.name}/h3 p价格span classprice${cake.price}/span 元/p a href${pageContext.request.contextPath}/cart/add?cakeId${cake.id}加入购物车/a /div /c:forEach /div % include file/WEB-INF/views/common/footer.jsp % /body /html这里有两个核心机制。第一是${pageContext.request.contextPath}它动态输出当前项目的部署路径也就是第2章里指定的/cake。不写死路径的原因是项目换个contextPath部署所有链接还能正常动。第二是JSTL的c:forEach循环它要求WEB-INF/lib下有jstl-1.2.jar和standard.jar同时JSP顶部声明taglib。漏了jar包时页面编译期不报错运行期才报The absolute uri cannot be resolved看到这个错误第一反应应该是检查jar而不是去改标签名。JSP里的一个原则不要往页面里写Java代码块。新手特别喜欢在% %里写for循环和if判断一时爽快后面一复杂就变成一团乱麻。用EL表达式和JSTL能覆盖90%的展示需求剩下的让Servlet在控制器层把数据组装好再放进request域。4.2 登录态与购物车Session会话和Cookie到底谁在起作用登录功能是JavaWeb里必须手写一遍的环节因为后面所有用户操作都依赖它。核心逻辑其实就十几行验证用户名密码后把用户对象放进Session再决定是否种CookieWebServlet(/login) public class LoginServlet extends HttpServlet { private final UserDao userDao new UserDao(); Override protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException { req.setCharacterEncoding(UTF-8); String username req.getParameter(username); String password req.getParameter(password); User user userDao.findByUsernameAndPassword(username, password); if (user ! null) { HttpSession session req.getSession(); session.setAttribute(loginUser, user); if (on.equals(req.getParameter(rememberMe))) { Cookie cookie new Cookie(USER_NAME, username); cookie.setMaxAge(7 * 24 * 60 * 60); cookie.setPath(req.getContextPath() /); resp.addCookie(cookie); } resp.sendRedirect(req.getContextPath() /index); } else { req.setAttribute(error, 用户名或密码错误); req.getRequestDispatcher(/login.jsp).forward(req, resp); } } }几个细节值得说透。doPost里第一行req.setCharacterEncoding(UTF-8)是解决中文参数乱码的开关对所有POST请求都要有GET请求的中文乱码则需要改Tomcat的server.xml给Connector加URIEncodingUTF-8。这两个地方漏一个都会复现第5章的乱码问题。session.setAttribute(loginUser, user)之后后面每个页面或Servlet拿当前用户只需要从Session里取。但注意Session默认超时时间是30分钟用户挂机太久购物车信息还在登录态却没了这是正常业务行为。处理办法是写一个简单的Filter拦截器Session为空就重定向到登录页而不是去调长Session生命周期。再谈购物车。Session版的数据模型天然是一个Map蛋糕ID, 数量完全贴合购物车这个业务概念而且不涉及落库逻辑public class Cart { private final MapInteger, CartItem items new LinkedHashMap(); public void addItem(CartItem item) { CartItem existing items.get(item.getCakeId()); if (existing ! null) { existing.setQuantity(existing.getQuantity() item.getQuantity()); } else { items.put(item.getCakeId(), item); } } public int getTotalCount() { return items.values().stream() .mapToInt(CartItem::getQuantity).sum(); } public BigDecimal getTotalPrice() { return items.values().stream() .map(CartItem::getSubtotal) .reduce(BigDecimal.ZERO, BigDecimal::add); } }这个Cart对象在用户点击“加入购物车”时从Session里取出来没有就新建一个放进去。Session版购物车的缺陷是换设备或清Cookie就没了。对课设来说这不是问题因为评分场景默认同一台机器完成操作。如果导师明确要求购物车持久化再落t_cart_item表做法很简单加入时INSERT删除时DELETE展示时JOIN t_cake查最新价格。4.3 商品搜索与分页PreparedStatement和URL参数的边界蛋糕列表页几乎必然要做的两个功能是搜索和分页。合在一起就暴露一个典型的新手错误直接用字符串拼接SQL。看这个不推荐的写法String sql SELECT * FROM t_cake WHERE name LIKE % keyword % LIMIT page , pageSize;这个写法有两个要命的问题keyword拼进百分号里可以被SQL注入page参数拼进LIMIT会被解析成想象不到的数值。正确写法是用PreparedStatement占位符String sql SELECT COUNT(*) FROM t_cake WHERE name LIKE ?; PreparedStatement ps conn.prepareStatement(sql); ps.setString(1, % keyword %); ResultSet countRs ps.executeQuery(); countRs.next(); int totalCount countRs.getInt(1); sql SELECT * FROM t_cake WHERE name LIKE ? ORDER BY id DESC LIMIT ?, ?; ps conn.prepareStatement(sql); ps.setString(1, % keyword %); ps.setInt(2, (page - 1) * pageSize); ps.setInt(3, pageSize); ResultSet rs ps.executeQuery();注意LIMIT后面的两个参数是offset和countoffset从0开始。第1页是LIMIT 0, 10第2页是LIMIT 10, 10换算公式是(page - 1) * pageSize。很多教程在这里直接传page进LIMIT第2页查出来确实是第11到20条但第一页LIMIT 1, 10会跳过第一条出现“列表页第一页少一个商品”的诡异bug。搜索的另一个细节是分页页码链接要带上一次搜索的关键字。JSP里生成分页标签时有直接拼参数的做法a href${pageContext.request.contextPath}/cake/list?page${p}keyword${param.keyword}但keyword里如果含中文或空格直接拼到URL会出现编码错乱。可以用JSTL的c:url标签自动编码c:url varpageUrl value/cake/list c:param namepage value${p}/ c:param namekeyword value${param.keyword}/ /c:url a href${pageUrl}${p}/ac:url会自动做URL编码比手拼字符串安全得多。我还见过一种翻车方式搜索关键字里带单引号比如搜“Cakes kitchen”直接字符串拼接导致SQL语法错误用PreparedStatement后这类问题全部消失。数据量大时再考虑索引优化在t_cake表的name字段建一个普通索引就够了。真正决定成绩的往往不是查询性能而是搜索时结果错乱这种功能性问题。5. JavaWeb蛋糕商城避坑指南五个高频翻车点从现象到根治5.1 IDEA里Tomcat启动成功但浏览器404先查contextPath和Artifact现象Tomcat控制台显示启动成功浏览器访问http://localhost:8080/cake/却404。这是IDEA里跑JavaWeb项目最最常见的问题每天都在重复发生。原因要么是Deployment里没把Artifact加进去项目根本没部署到Tomcat的webapps目录Tomcat启动的是空服务要么是Application context配错了你访问/cake但实际配的是/。解决打开Run/Debug Configurations看Deployment标签页下有没有项目的war exploded条目再看Application context是不是/cake。改完之后重启Tomcat不要用热更新热更新对Deployment结构变化不生效。还不行就看Tomcat的webapps目录里有没有项目文件夹没有就说明Artifact还是没部署上。IDEA里最常见的牛角尖是把Tomcat配到了Deployment之外的项目结构里实际上Tomcat只认Deployment标签页里那一份。5.2 MySQL中文数据全变问号三处字符集必须一致现象往数据库插入中文蛋糕名页面上或数据库里显示成“???”。有人因为这个重装MySQL、换驱动、改代码最后发现只是少写一个参数。原因MySQL的character_set_server、数据库的charset、JDBC连接URL的characterEncoding三处只要有一处不是utf8或utf8mb4中文就出问题。最常见的是JDBC URL里没加characterEncodingutf8。解决第一建表语句统一加DEFAULT CHARSETutf8mb4第二JDBC URL写成下面这种完整形式jdbc:mysql://localhost:3306/cake_shop?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue第三核对MySQL配置文件my.ini里[mysqld]段有character-set-serverutf8mb4。按这个顺序排查90%的乱码出在JDBC URL。改完URL后记得重启Tomcat连接池里的旧连接不会自动刷新。5.3 JSP里EL表达式原样输出web.xml版本与JSTL jar包没对上现象页面上直接显示${cake.name}字符串而不是蛋糕名称c:forEach标签被浏览器当成普通文本。看起来像代码写错了其实是配套环境不对。原因JSP里启用EL表达式要求web.xml的Servlet版本在2.4以上Tomcat 8默认支持。但如果项目里放了一份老旧的web.xml声明为2.3EL表达式会被当成普通文本输出。JSTL同理lib下没有jstl和standard这两个jarJSTL标签也无法解析。解决打开web.xml确认根元素声明版本为3.1或4.0大致写法是web-app xmlnshttp://xmlns.jcp.org/xml/ns/javaee xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd version3.1检查WEB-INF/lib下是否有jstl-1.2.jar和standard-1.1.2.jar。如果都没问题把IDEA的缓存清掉再重启一次JSP编译缓存有时会留下旧版本的片段。5.4 登录后刷新就掉线JSESSIONID与Cookie路径的纠缠现象登录成功跳到首页正常但刷新页面或跳转下一个页面后登录状态消失又要重新登录。原因Session依赖浏览器Cookie里的JSESSIONID。如果Cookie没有被正确种下或每次请求JSESSIONID都变了Session就永远对不上表现就是“登录就掉”。常见诱因有两个项目路径和Cookie的path不匹配代码里手动创建了一个同名Cookie覆盖了JSESSIONID。解决浏览器F12看Network面板检查两次请求的Cookie头里JSESSIONID是否一致。如果不一致说明Cookie没写进浏览器。检查代码里有没有手动new Cookie(JSESSIONID, ...)有就删掉再检查Cookie.setPath是否设置为req.getContextPath() /。如果本地没问题、部署到服务器才出现优先检查Tomcat的session cookie配置和域名可以把session超时时间调长到30分钟以上再说。5.5 数据库连不上报Public Key RetrievalMySQL 8.0认证插件和驱动类现象程序启动后第一次访问数据库报java.sql.SQLNonTransientConnectionException: Public Key Retrieval is not allowed。原因MySQL 8.0默认使用caching_sha2_password认证插件客户端首次连接时需要从服务器获取公钥做加密握手JDBC URL里没允许这个行为就会抛异常。另外驱动jar是5.x还是8.x也决定了驱动类名完全不同。解决连接URL加上allowPublicKeyRetrievaltrue同时带上useSSLfalse避免加密认证的另一层干扰。确认驱动类是com.mysql.cj.jdbc.Driver而不是com.mysql.jdbc.Driver。这个坑最容易出现在本地MySQL 8.0、教程代码却按5.x驱动写的场景。排查顺序是先看jar在不在WEB-INF/lib再看URL参数齐不齐最后看驱动类名对不对。6. 从能跑到能看日志、演示数据与部署细节的最后一公里6.1 用日志和断点把Bug定位时间砍掉一半代码能跑之后第一件事是加日志而不是加功能。在黑匣子阶段System.out.println打印的信息没有级别、没有时间戳你不知道哪条日志是哪里打的。我通常会用Log4j2做最小配置log4j2.xml放在src/main/resources下根Logger级别设为DEBUG把MySQL驱动之类的第三方日志级别调成WARN避免刷屏。这样MySQL驱动和框架类的调试信息不会干扰你自己业务代码里的logger.info和logger.error能显示完整堆栈和时间。配上日志后再遇到乱码或Session丢失你从日志看到的不再是“页面白屏”而是具体的异常行和参数值。IDEA里同时打几个断点配合日志看变量值变化定位时间能砍掉一半。6.2 用初始化脚本准备演示数据不在现场造数据演示环节最怕临时录入数据翻车每插入一条重启一次Tomcat。我习惯把演示数据反过来准备把分类、商品、测试账号、若干条订单全部写进初始化脚本现场用干净浏览器环境演示登录、加购、下单流程。脚本里除了基础数据再多插几笔状态为0的订单现场演示结算时直接就能看到待支付订单列表。注意测试账号的密码不要用加密逻辑因为Demo场景里评委可能现场重新登录纯文本密码最简单也最稳。演示前从浏览器开发者工具里勾选Disable cache再强制刷新两次页面模拟真实用户的访问链路。6.3 部署到服务器时的三个细节部署到云服务器时有三个比本地更容易出问题的地方。第一是数据库连接项目和服务在同一台机时数据库URL写localhost没问题但云服务器的防火墙和安全组要放行3306端口否则外部连不上。第二是Tomcat端口8080要在安全组里放行想用80端口需处理root权限问题两难时就保留8080用Nginx做反向代理。第三是静态资源路径页面里所有${pageContext.request.contextPath}会自动适配部署路径反过来说如果早前图省事写死了/cake部署后这些链接会全部失效这也是我坚持所有URL不写死的原因。每个项目做到最后一公里拼的往往不是技术难度而是这些细节的闭环。我自己带过的学生里不少人在本地跑得顺一到服务器演示就慌。后来我养成了一个习惯每次部署完先从浏览器禁用缓存并强制刷新两次再走一遍登录、加购物车、结算、后台管理这几个主链路全部通过才算完。这个习惯帮我避开了很多线上翻车现在也分享给你希望帮到你。本文还有配套的精品资源点击获取