JSP+Servlet实战：早餐外卖管理系统（JavaWeb全栈项目）-AI智能范式网

我前前后后带过不少实习生，也帮人看过几十份JavaWeb课程的期末项目，发现一个规律：凡是自己从零搭过一遍Servlet+JSP项目的人，后面学Spring Boot、学微服务，理解速度都会快一大截。而那些直接上手Spring Boot的，反而经常卡在"过滤器是什么""监听器干嘛的""请求到Controller之前发生了什么"这些问题上。

这篇要聊的项目原型，就是一个典型的JavaWeb全栈训练场景——JSP+Servlet+JavaScript+MySQL实现的早餐外卖店管理系统。它覆盖了JavaWeb阶段最常见的一套能力点：用户登录注册、菜品展示、购物车、下单、后台管理。不涉及Spring、不涉及MyBatis，纯粹用最原始的Servlet手写逻辑、用JDBC连MySQL、用JSP渲染页面，整套跑通之后，你对JavaWeb的理解会有一个质的变化。

这个项目适合正在学JavaWeb、准备做课程设计或者想夯实基础的人。下面我把整个项目的设计思路、核心实现、踩坑记录完整拆开讲。

1. 早餐外卖管理系统到底要做什么：需求拆解与功能边界

做项目最忌讳一上来就写代码。先想清楚，一个早餐外卖系统，用户打开页面之后核心动作是什么？无非是"浏览早餐→加购→下单→（商家）接单处理"。再往细了拆，会有几个关键画面：

顾客端：

注册/登录：不同角色（顾客、商家/管理员）分开
菜单浏览：按早餐分类展示（粥品类、面点类、豆浆/饮品、套餐类）
购物车：加购、减数量、清空、算总价
下单：提交订单、填写备注
订单列表：查看自己历史订单和状态

管理端：

菜品管理：新增、修改、上下架、改价格
分类管理：维护早餐分类
订单处理：查看新订单、标记接单/完成

这些功能看起来多，实际落到JavaWeb技术上，其实都是"表单向Servlet发请求 → Servlet调DAO操作数据库 → 转发或重定向到JSP页面"这个循环。难点不在于单个功能，而在于把每个环节的代码写清楚、把数据流转理顺畅。

我见过太多人做这类项目时，把代码全堆在Servlet里，JSP里又嵌了一大堆Java逻辑，结果改一个需求要动七八个文件。所以做这个项目时，我建议一开始就给自己定一个规矩：Servlet只做请求接收和流程控制，业务逻辑单独抽出来，数据库访问统一走DAO层，JSP里只允许出现JSTL和EL，严禁写Scriptlet。 这个规矩坚持住，项目后期会省非常多力气。

这个项目最适合拿来当课程设计或者练手项目的另一个原因是：早餐外卖的业务逻辑相对简单，但五脏俱全。它比"图书管理系统"多了购物车和订单状态流转，比"新闻发布系统"多了权限区分，刚好卡在一个"能学到东西又不会太难"的位置上。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 为什么用JSP+Servlet而不用Spring Boot：技术选型背后的真实考量

有人可能会问，现在公司里都用Spring Boot了，为什么还要用Servlet+JSP这种"老古董"？这个问题我在指导项目时被问过无数次。原因很简单：这是一个教学项目，它存在的意义是让你把Web底层原理吃透。

JSP+Servlet这套组合的背后，是整个JavaWeb最核心的请求处理链路：浏览器发HTTP请求 → Tomcat接收，根据web.xml中的映射关系找到对应的Servlet → Servlet调用service()（或doGet()/doPost()）方法 → Servlet通过HttpServletRequest读参数、通过HttpSession管理会话、通过HttpServletResponse写响应 → 数据通过RequestDispatcher转发到JSP渲染HTML。

这条链路上每一步都是后面学习Spring Boot的基石。你要是直接学Spring Boot，DispatcherServlet对你来说就是个黑盒，请求怎么进来、视图怎么渲染，你都只能背概念。而手写一遍Servlet，这些概念全变成你亲手敲过的代码。

另外，从完成课程设计的角度来说，JSP+Servlet有几个实打实的优势：

部署简单：打包成WAR丢到Tomcat的webapps下面就能跑，不需要像Spring Boot那样关心内嵌服务器和外部Tomcat的关系。
调试直观：出错时Tomcat的日志、IDEA的控制台、浏览器开发者工具，三者一对照，基本能定位问题。
数据库操作透明：全程用JDBC直连MySQL，SQL语句全在自己手里，每个查询、每个事务都看得见，不像MyBatis/JPA那样帮你封装了一层。

那JSP+Servlet的缺点要不要说？当然要说。这个方案最大的缺点是：前后端耦合严重、页面渲染效率低。JSP在服务端渲染，每次请求都要把Java代码和HTML拼在一起输出，大型项目根本hold不住。这也是为什么现在主流项目逐渐转向前后端分离，前端用Vue/React，后端用Spring Boot提供JSON接口。但作为学习项目，它的"笨"反而成就了它的"透"——你看到的每一行代码都知道在干什么。

3. 数据从哪里来、怎么存：MySQL表结构设计的完整拆解

数据库是整个系统的心脏。早餐外卖系统的表结构设计，我建议按照"一个中心、三条主线"的思路来：

一个中心：user用户表，所有角色的基础。
三条主线：菜品/分类（商品线）、购物车/订单（交易线）、订单明细（履约线）。

具体拆开看：

code复制user
- id          INT PK AUTO_INCREMENT
- username    VARCHAR(50) UNIQUE
- password    VARCHAR(100)       -- 建议MD5或SHA加密存储
- role        TINYINT            -- 1=顾客 2=管理员
- phone       VARCHAR(20)
- address     VARCHAR(200)
- created_at  DATETIME

category
- id          INT PK AUTO_INCREMENT
- name        VARCHAR(50)

dish
- id          INT PK AUTO_INCREMENT
- name        VARCHAR(100)
- category_id INT FK -> category.id
- price       DECIMAL(10,2)
- image_url   VARCHAR(255)
- description VARCHAR(255)
- status      TINYINT            -- 1=上架 0=下架

cart
- id          INT PK AUTO_INCREMENT
- user_id     INT FK -> user.id
- dish_id     INT FK -> dish.id
- quantity    INT
- UNIQUE KEY(user_id, dish_id)   -- 同一用户同一菜品只有一条记录

orders
- id              INT PK AUTO_INCREMENT
- order_no        VARCHAR(32) UNIQUE  -- 商户订单号，下单时生成
- user_id         INT FK -> user.id
- total_amount    DECIMAL(10,2)
- status          TINYINT        -- 1=待接单 2=制作中 3=已完成 4=已取消
- remark          VARCHAR(255)
- created_at      DATETIME

order_item
- id          INT PK AUTO_INCREMENT
- order_id    INT FK -> orders.id
- dish_id     INT FK -> dish.id
- dish_name   VARCHAR(100)      -- 冗余字段：防止菜品改名后历史订单变化
- price       DECIMAL(10,2)     -- 冗余字段：记录下单时价格
- quantity    INT

这套设计有几个值得说道的点：

第一，购物车表加唯一键。 (user_id, dish_id)的联合唯一约束意味着同一个用户的购物车里同一个菜品只有一条记录，加购逻辑就是"有则数量+1，无则插入新行"。这个操作用一条INSERT ... ON DUPLICATE KEY UPDATE quantity = quantity + 1就能完成，既省了一次查询又防了并发重复插入。我第一次用这个语法时简直觉得捡到了宝。

第二，订单明细冗余了dish_name和price。 这是很多新手不会考虑到的：如果有一天你把"皮蛋瘦肉粥"改名成"瘦肉皮蛋粥"或者把价格从8块涨到10块，以前下的订单按头查询时怎么办？如果没有冗余字段，你只能通过dish_id去菜品表查，查到的是"现在的名字"和"现在的价格"，历史订单就失真了。冗余看似浪费存储，实际是保住了订单数据的完整性。

第三，金额字段用DECIMAL不用FLOAT。 数据库设计老生常谈，但真的一堆人栽在这上面。FLOAT是近似存储，8块3角5分的商品你算三个的总价可能得到25.04999999，打印到页面上就露馅了。DECIMAL(10,2)是精确存储，专门干这事的。

第四，订单号设计。 主键id其实不宜直接当订单号展示给用户，因为它自增且规律性太强，不适合做对外标识。我习惯在orders表里加一列order_no，生成规则取"年月日时分秒+用户ID+随机数"。Java里用SimpleDateFormat + System.nanoTime()拼一下就够用，不用搞太复杂。

表建好之后，别急着写代码。先往category和dish表里塞一批模拟数据（豆浆油条、皮蛋瘦肉粥、小笼包、茶叶蛋……），这样后面写前端页面时不会空荡荡的。

sql复制INSERT INTO category (name) VALUES ('粥品类'), ('面点类'), ('饮品豆浆'), ('经典套餐');

INSERT INTO dish (name, category_id, price, image_url, description, status) VALUES
('皮蛋瘦肉粥', 1, 8.50, 'images/porridge.png', '招牌暖胃早餐', 1),
('鲜肉小笼包', 2, 6.00, 'images/dumpling.png', '皮薄馅大', 1),
('现磨豆浆', 3, 3.50, 'images/soymilk.png', '每日现磨', 1);

MySQL这边有几个前置动作必须做对：字符集要选utf8mb4，排序规则选utf8mb4_general_ci（或者utf8mb4_unicode_ci）；连接串里带上useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai，否则后面全是中文乱码的噩梦。

4. 从登录到下单：核心功能模块的实现思路逐层拆解

系统功能再多，核心还是那几个关键流转。我把每个模块的实现思路和关键代码整理一下，你照着这个思路写，基本不会跑偏。

4.1 登录与会话管理

登录是整个系统的入口，也是后面所有权限控制的基础。思路很简单：登录表单POST到/login，Servlet里调DAO按用户名查出用户，比对密码（这里注意，数据库存的应该是MD5或SHA-256的摘要，而不是明文），匹配成功就把用户对象放进HttpSession，然后根据role字段决定跳转到客户首页还是管理后台；匹配失败就带上错误提示回登录页。

关键点在于密码加密。我见过太多直接用明文存密码的作业了，这在正规项目里是不可接受的。Java里用MessageDigest做MD5或SHA-256也就几行代码：

java复制public static String md5(String source) {
    try {
        MessageDigest md = MessageDigest.getInstance("MD5");
        byte[] bytes = md.digest(source.getBytes(StandardCharsets.UTF_8));
        StringBuilder sb = new StringBuilder();
        for (byte b : bytes) {
            String hex = Integer.toHexString(b & 0xff);
            if (hex.length() == 1) sb.append("0");
            sb.append(hex);
        }
        return sb.toString();
    } catch (NoSuchAlgorithmException e) {
        throw new RuntimeException(e);
    }
}

注册时password存md5(原始密码)，登录时把用户输入的密码也MD5一次再比对。这样数据库就算被拖出去，也拿不到明文密码。

会话管理这块，重点理解request.getSession()和session.setAttribute("user", user)这两个调用。JavaWeb的会话机制是：第一次getSession()时（实际上是在服务器第一次创建Session并给浏览器种一个JSESSIONID的Cookie之后），服务器在内存里存一份Session数据，同时通过Set-Cookie把SessionID发给浏览器，浏览器后续每次请求都会带上这个Cookie，服务器据此找到对应的Session。这就是"会话保持"的底层逻辑，也是Servlet程序员的必修课。

4.2 菜品展示与图片资源处理

菜品列表页是最直接面对用户的一个页面。实现上典型的流程是：DishServlet收到/dish/list请求，调DAO执行SELECT d.*, c.name AS category_name FROM dish d JOIN category c ON d.category_id = c.id，得到List<Dish>之后放进request，request.getRequestDispatcher("menu.jsp").forward(request, response)转发到JSP页面。

菜单页用JSTL循环渲染：

jsp复制<c:forEach items="${dishList}" var="dish">
  <div class="dish-card">
    <img src="${dish.imageUrl}" alt="${dish.name}" />
    <h4>${dish.name}</h4>
    <p class="price">￥${dish.price}</p>
    <button onclick="addToCart(${dish.id}, '${dish.name}', ${dish.price})">加入购物车</button>
  </div>
</c:forEach>

这里涉及一个热搜词列表里出现的问题——JSP图片如何对坐标定位。很多人会把菜品图片放在webapp/images目录，然后<img src="images/porridge.png">。但经常遇到图片显示不出来的情况，原因一般是三个：

路径问题：在转发到JSP时，浏览器地址栏的URL和JSP实际路径不一致，相对路径images/xxx.png就定位错了。最稳妥的解法是用绝对路径：src="${pageContext.request.contextPath}/images/xxx.png"。${pageContext.request.contextPath}会动态拼出应用的部署根路径，比如/breakfast，这样不管你在哪个页面都不会傻掉。
文件名/大小写问题：Linux上的Tomcat对文件名大小写敏感，Porridge.png和porridge.png是两个文件。Windows上开发没事，一部署到服务器就挂。建议统一小写。
静态资源被过滤器拦截：有些项目给所有URL配了/*路径的字符编码Filter，如果Filter实现里直接chain.doFilter()没问题，但如果判断逻辑有问题，静态资源可能被拦下来。解决办法是让Filter只拦截.do或指定Servlet路径。

至于"坐标定位"，如果你需要在图片上做热点区域（比如点击菜品图片的某个区域加购），HTML原生有<map>和<area>标签可以干这事，根本不需要额外依赖。<area>标签支持圆形circle、矩形rect、多边形poly三种形状，配合coords属性指定坐标即可。例如：

html复制<img src="menu-board.png" usemap="#breakfastMap" />
<map name="breakfastMap">
  <area shape="rect" coords="10,20,110,120" alt="皮蛋瘦肉粥" href="dishDetail?id=1" />
  <area shape="circle" coords="240,80,50" alt="小笼包" href="dishDetail?id=2" />
</map>

4.3 购物车与总价计算

购物车是早餐外卖系统里"含金量"最高的模块，因为它牵扯到会话内共享数据、集合CRUD、金额计算，是个练脑子的好东西。

购物车的数据放哪里？两种方案：

方案A：放在Session中，用一个Map<Dish,Integer>或者Map<Integer,Integer>（dishId→数量）来存。好处是读写快、不用碰数据库；坏处是用户关浏览器数据就没了，换设备也看不到。
方案B：放在数据库的cart表里，持久化到MySQL。好处是用户下次登录购物车还在；坏处是多了一层数据库读写。

我建议做方案B，因为整个系统逻辑统一在数据库里，后面统计、清理都方便，也更接近真实项目。只有做Demo演示时为了省事才用Session。

购物车的核心操作有三个：

加购：前端JS获取菜品ID和数量，fetch("cart/add?dishId=" + id + "&quantity=1")发起请求。后端CartServlet拿到当前登录用户的ID（从Session里取），执行INSERT ... ON DUPLICATE KEY UPDATE quantity = quantity + 1。注意，加购接口必须是POST请求，不能用GET，因为GET可以被URL直接触发，爬虫或者预加载脚本可能会把购物车塞爆，这个习惯最好从一开始就养成。

展示：查询时SELECT d.id, d.name, d.price, c.quantity FROM cart c JOIN dish d ON c.dish_id = d.id WHERE c.user_id = ?，然后在前端算出本条小计，再汇总总价。总价计算可以在Java里做完存到request，也可以在前端JS里算。我推荐前端算，因为用户体验更流畅——改数量、删一项，总价立刻变，不用重新请求后端。

javascript复制function updateTotal() {
    let total = 0;
    document.querySelectorAll('.cart-item').forEach(item => {
        const price = parseFloat(item.dataset.price);
        const qty = parseInt(item.querySelector('.qty-input').value);
        total += price * qty;
    });
    document.getElementById('totalAmount').textContent = total.toFixed(2);
}

这里有个细节：toFixed(2)保留两位小数，防止浮点误差导致总价显示成一长串小数。

删除/改数量：增删改查都有了，补一个注意点——修改数量建议走POST的cart/update?dishId=1&quantity=3接口，后端校验quantity必须≥1，超过库存（如果有库存概念）就拒绝。防的是有人把所有菜品数量改成0甚至-1，把订单总额搞成负数。

4.4 下单流程与事务控制

下单是整个系统里事务性最强的一段操作，也是我建议你在课程设计答辩时重点讲的部分。下单逻辑要分成三步（这里不考虑减库存，早餐店一般库存简单）：

在orders表插入一条订单记录，拿到自增主键orderId；
遍历购物车明细，逐条插入order_item表；
清空该用户的购物车。

这三步要么全成功、要么全失败。比如说订单插入了明细没插入，用户付了钱却看不到自己买了什么；或者明细插入了购物车没清空，下次登录购物车还在，用户可能重复下单。所以必须用事务包住。

JDBC事务的标准写法：

java复制Connection conn = null;
try {
    conn = DBUtil.getConnection();
    conn.setAutoCommit(false);  // 关闭自动提交，开启事务

    // 1. 插入订单
    // 2. 批量插入订单明细
    // 3. 清空购物车

    conn.commit();               // 全部成功才提交
} catch (SQLException e) {
    if (conn != null) conn.rollback();  // 任何一步失败，全部回滚
    throw e;
} finally {
    if (conn != null) {
        conn.setAutoCommit(true);
        conn.close();
    }
}

这比"逐条执行然后祈祷不出错"强了一百倍。我印象很深，有一次我在做这个模块时，故意在插明细的SQL后面放了一个必错的字段名，测试时下单页直接报错，但订单表里也只有一条孤儿数据。改成事务之后，同样的错误，订单表和明细表都是干干净净的，这就是事务的价值。

4.5 管理员端菜品管理与页面刷新刷新时机

管理员端的代码逻辑其实比客户端简单，就是常规的增删改查。但这里有一个热搜词很有意思——"JSP页面让加载完后刷新一次"。这个需求你在做菜品管理时很可能会遇到：管理员在"新增菜品"表单页提交完，后端处理完sendRedirect到菜品列表页，但浏览器可能还停留在旧页面上（尤其是按了F5重新提交表单的情况）。

处理手法是在提交成功后的响应里输出一段刷新脚本：

jsp复制<script type="text/javascript">
    window.onload = function() {
        if (performance.navigation.type === 1) {  // 1表示页面是通过刷新加载的
            location.reload();
        }
    };
</script>

不过说实话，这种"让页面加载完后刷新一次"的招数属于偏方，正规做法是：处理完POST请求后用sendRedirect重定向到列表页，而不是forward转发。重定向会让浏览器重新请求列表页，天然规避了表单重复提交和页面陈旧问题。JavaWeb的最佳实践是"POST-Redirect-GET"，这个模式一定要记住。如果用了重定向还觉得页面数据旧，多半是Servlet缓存了旧数据，检查一下Session里是不是丢了新的列表。

5. 实测踩坑实录：从编码到部署的五个深坑

这个项目我完整跑过不止一遍，以下是每次都会遇到的坑，按出现频率排序。你照着这个清单提前打预防针，能少踩一大半。

5.1 中文乱码：前端、后端、数据库三层都要管

中文乱码是JavaWeb项目里出现频率最高的幺蛾子，没有之一。乱码的根源其实就一句话：数据在不同环节之间流转时，编码方式不一致。所以排查乱码要按三层查：

第一层：JSP页面本身。 在JSP最顶部加上：

jsp复制<%@ page contentType="text/html;charset=UTF-8" language="java" %>

同时确保页面文件的编码也是UTF-8（IDEA右下角能看，不是的话右下角切换）。如果JSP页面没有pageEncoding="UTF-8"属性，Tomcat可能按ISO-8859-1来读这个文件，中文全变问号。

第二层：Servlet接收请求参数。 在Servlet里（或者更正规地，在Filter里）加上：

java复制request.setCharacterEncoding("UTF-8");

注意，这个设置必须在第一次读取参数之前调用，否则对POST请求参数无效。GET请求的查询参数用的是Tomcat默认URI编码（通常是UTF-8），如果乱码，要到Tomcat的server.xml里给<Connector>标签加URIEncoding="UTF-8"。

第三层：数据库连接。 连接串上拼：

code复制jdbc:mysql://localhost:3306/breakfast?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Asia/Shanghai

表结构那里提过，这里不再重复。三管齐下之后，中文字符基本不会再出事。如果还是乱，用curl或者浏览器开发者工具看响应头里Content-Type是不是带了charset=UTF-8，大概率是漏了第一层的page指令。

5.2 表单重复提交：敲一次回车订了两单

下单按钮被快速点了两次、或者用户提交订单后发现没反应又点了一次，购物车清空订单却生成了两单——这种事在测试时必须防。

防法一共有三道闸：

前端JS闸：下单按钮提交后立刻disabled，文字变成"正在提交..."，杜绝手快的用户。
前端Token闸：下单页预先从服务端拿一个随机token存到session和页面的隐藏域里，提交时带上，后端比对两次token是否一致，一致则消费掉；不一致说明重复提交，直接拒绝。
后端重定向闸：处理完订单不forward到成功页，而是sendRedirect到"下单成功"URL。这样就算F5刷新，也只是刷新成功页，不会重新走一遍下单逻辑。

课程设计阶段做到第一和第三道就够亮眼了，第二道是加分项。

5.3 连接池与数据库连接泄漏：能LOCAL演示，上点压力就滚出最严重的问题

如果只是为了跑通Demo，DriverManager.getConnection()写完马上close()也没毛病。但你要是演示的时候连续点了几十次下单，突然有一次特别卡，过一会儿又恢复正常，多半是连接没关干净——MySQL默认的最大连接数是151，连接全被占用时新请求就只能排队等超时。

我在这个项目里最后用了Druid连接池，只在pom.xml（或者WEB-INF/lib的jar包）里引一下，配置一个druid.properties：

code复制driverClassName=com.mysql.cj.jdbc.Driver
url=jdbc:mysql://localhost:3306/breakfast?useUnicode=true&characterEncoding=UTF-8
username=root
password=123456
initialSize=5
maxActive=20

然后用DruidDataSourceFactory.createDataSource得到一个DataSource，所有DAO层都从这个数据源拿连接：

java复制public static Connection getConnection() {
    try {
        return dataSource.getConnection();
    } catch (SQLException e) {
        throw new RuntimeException(e);
    }
}

更重要的是养成一个肌肉记忆：连接用完之后在finally块里关，或者用Java 7的try-with-resources语法，让Connection、PreparedStatement、ResultSet都在try后面跟括号里声明，方法结束自动关闭。

java复制try (Connection conn = DBUtil.getConnection();
     PreparedStatement ps = conn.prepareStatement(sql)) {
    ps.setInt(1, userId);
    try (ResultSet rs = ps.executeQuery()) {
        while (rs.next()) {
            // ...
        }
    }
} catch (SQLException e) {
    e.printStackTrace();
}

5.4 JS运行时报错与`Cannot read properties of undefined`

这个项目里JavaScript主要用于购物车和页面交互。最容易踩的报错是"页面一打开控制台就报错，界面瘫了一半"。

新手最常见的写法是脚本直接操作还不存在的DOM元素：

javascript复制document.getElementById('totalAmount').textContent = ...;

如果totalAmount这个元素还没渲染到页面上，脚本执行到这一行就直接报错。解决思路有两个：

把<script>标签放到</body>之前，保证DOM树已经构建完；
或者把逻辑包在window.onload = function(){...}里。

我们在测试时也经常遇到异步请求返回的数据结构和预期不符。比如fetch("cart/list")返回的JSON经常包了一层，前端忘了解包。开发时养成习惯：先console.log(res)看结构，再写业务逻辑，能省一大半调试时间。

5.5 MySQL版本选择与安装配置：5.7还是8.0

热搜词里有一堆MySQL安装相关的词条，说明大家对这个环节很头疼。我的建议非常明确：本地开发用MySQL 5.7，部署到云服务器再用8.0都行，但5.7的坑最少。为什么？因为网上教程针对5.7的最多、JDBC驱动兼容性最稳、内存占用也低。8.0的坑主要在：caching_sha2_password认证插件默认启用，老版本的mysql-connector-java 5.x不认识这个插件，会报"Public Key Retrieval is not allowed"；另外8.0对SQL语法的校验更严格。

如果你用8.0，驱动要用com.mysql.cj.jdbc.Driver（新版驱动类名和旧版不同），URL还要带上allowPublicKeyRetrieval=true配合serverTimezone=Asia/Shanghai：

code复制jdbc:mysql://localhost:3306/breakfast?useSSL=false&allowPublicKeyRetrieval=true&serverTimezone=Asia/Shanghai&characterEncoding=UTF-8

Windows上装MySQL两个坑一定注意：安装目录不要有中文和空格；服务安装完默认大小写敏感是否开启，取决于配置文件初始化参数，如果要大小写不敏感，安装完成后在my.ini的[mysqld]下加一行lower_case_table_names=1重启服务。这行配置翻译成人话就是：让表名不区分大小写。

6. IDEA里跑通JavaWeb项目：从部署到调试的完整闭环

这部分对新手特别重要，而且热搜词里明明白白写了"idea运行javaweb项目配置"，说明很多人卡在这一步。

6.1 项目结构搭建

在IDEA里新建Web项目的正确姿势（推荐手动建，不要用模板生成器）：

code复制breakfast-store/
├── pom.xml (如果用Maven管理依赖)
├── src/
│   └── main/
│       ├── java/
│       │   └── com/breakfast/
│       │       ├── entity/
│       │       ├── dao/
│       │       ├── service/
│       │       ├── servlet/
│       │       └── util/
│       ├── resources/
│       │   └── db.properties
│       └── webapp/
│           ├── WEB-INF/
│           │   ├── web.xml
│           │   └── lib/
│           ├── css/
│           ├── js/
│           ├── images/
│           └── *.jsp

这里提醒一嘴：如果不用Maven而是直接在WEB-INF/lib下放jar包，千万别忘了放**mysql-connector-java驱动jar包和jstl、standard这两个JSP标准标签库的jar包**。少一个，JSP页面里<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>就算写了，EL表达式也不会被解析。

6.2 Tomcat配置与热部署

IDEA里跑Tomcat步骤很固定：

菜单Run → Edit Configurations → 点+号 → Tomcat Server → Local；
在Server标签页里选Tomcat路径（注意，要选到Tomcat的根目录，不是bin目录）；
Deployment标签页 → 点+号 → Artifact → 选择breakfast-store:war exploded（爆炸式部署，意思是用解压目录跑，方便热更新）；
Application context设为/breakfast（和数据库连接串、前端contextPath保持一致）；
启动前把MySQL服务启好，确认表和数据都在。

之后每次改代码，右键选Update（快捷键Ctrl+F10）就能热更新。如果改的是web.xml、Servlet注解这类部署描述符，可能需要Redeploy。

6.3 调试三板斧

项目跑通不等于没有问题，你要学会三板斧：

第一板斧：看控制台日志。 Tomcat的日志会清楚打印出异常堆栈。看到ClassNotFoundException先检查jar包；看到SQLException: Table doesn't exist先检查数据库名和表名是否一致；看到HTTP Status 404排查Servlet映射路径；看到405通常是POST/GET写反了。

第二板斧：打断点。 在Java代码里打断点时，IDEA会停住并显示当前调用栈和变量值。不管是在Servlet的doGet里查request参数，还是在DAO层看SQL执行返回值，断点永远比System.out.println高效。

第三板斧：浏览器F12看网络请求。 页面报错时，打开开发者工具的Network面板，选中报错的那个请求，看一眼Request Method、URL、Status Code、Response Body。很多时候前端表现出的"页面没反应"，实际上是后端返回了500，前端JS没有处理错误分支直接忽略了。学会看Network面板，你能省掉一次"来来回回改代码重启Tomcat"的时间。

7. 账号体系、会话失效与权限拦截：最容易忽略的细节

很多JavaWeb项目做完之后，"登录功能看起来是有的，但同样的问题摆在面前：不登录也能直接访问下单页、管理页"。这个漏洞在答辩时要是被老师指出来，印象分会掉很多。

解决方案是用Filter实现统一登录校验与权限拦截。Filter是Servlet规范里的三大组件之一（另外两个是Servlet和Listener），它能在请求到达Servlet之前做拦截，也能在响应返回给客户端之前做处理。拦截逻辑很简单：

java复制public class AuthFilter implements Filter {
    public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain)
            throws IOException, ServletException {
        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) resp;

        String uri = request.getRequestURI();
        // 放行登录、注册、静态资源
        if (uri.endsWith(".css") || uri.endsWith(".js") || uri.endsWith(".png")
            || uri.endsWith("login.jsp") || uri.contains("/login")
            || uri.contains("/register")) {
            chain.doFilter(request, response);
            return;
        }

        HttpSession session = request.getSession(false);
        // 没有登录就跳回登录页
        if (session == null || session.getAttribute("user") == null) {
            response.sendRedirect(request.getContextPath() + "/login.jsp");
            return;
        }

        // 管理员页面只允许role=2访问
        if (uri.contains("/admin/")) {
            User user = (User) session.getAttribute("user");
            if (user.getRole() != 2) {
                response.sendError(HttpServletResponse.SC_FORBIDDEN);
                return;
            }
        }
        chain.doFilter(request, response);
    }
}

注册好Filter：

xml复制<filter>
    <filter-name>AuthFilter</filter-name>
    <filter-class>com.breakfast.filter.AuthFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>AuthFilter</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

话题延伸一下：会话失效问题。默认Tomcat的Session超时时间是30分钟，也就是说用户点了一份早餐加进购物车，过了30分钟没下单，再提交时发现Session里用户对象还在，但购物车已经丢了（方案B存的数据库里，购物车不会丢，这点也是选数据库方案的好处）。要不要改超时时间？早餐外卖这种场景，用户往往是早上着急下单，30分钟绰绰有余。但建议在web.xml里显式写上会话超时时间，别用默认值：

xml复制<session-config>
    <session-timeout>30</session-timeout>
</session-config>

另外还有一个容易疏漏的点：用户点击"退出登录"时，必须做两件事——调session.invalidate()销毁会话，并清除浏览器里的Cookie（尤其是JSESSIONID）。用Cookie cookie = new Cookie("JSESSIONID", null); cookie.setMaxAge(0); response.addCookie(cookie);。否则用户退出后，点击浏览器的后退按钮还能看到上一个登录用户的历史页面缓存。

8. 数据库边界场景处理：排序、默认值、锁与事务，那些面试官爱问的点

做这个项目时搞定细节，也是在给自己积累面试素材。这里把MySQL相关的几个边界知识和这个项目的关系串一遍。

8.1 菜品排序：除了价格排序还有权重排序

菜品列表默认展示顺序，我建议按分类+权重/创建时间排序，而不是数据库的自然顺序：

sql复制SELECT * FROM dish ORDER BY category_id ASC, sort_weight DESC, created_at DESC;

sort_weight是人为指定的字段，比如招牌早餐权重100、普通早餐权重50。这个设计在真实业务里很常见——运营想让某个菜品排在前面，直接改权重数字就行，不用改表结构。早餐店想主推"店长推荐套餐"，那这条菜就可以给一个大权重，页面一刷新就浮到最上面。

还有列表页的分页。\如果菜品一多（比如30道），总不能一次全查出来吧。经典实现是LIMIT ?, ?配合前端传page、pageSize：

java复制int page = Integer.parseInt(request.getParameter("page"));
int pageSize = 10;
int offset = (page - 1) * pageSize;
String sql = "SELECT * FROM dish LIMIT ?, ?";

数总数用COUNT(*)，算出总页数，前端生成一页一页的页码分组。这块做好，你的简历上就能写"实现菜单分页浏览"。

8.2 字段默认值与数据完整性

热搜词里有"mysql设置默认值为0"，这正是个常见需求。比如菜品status字段，希望默认是上架（1），直接在DDL里写：

sql复制status TINYINT NOT NULL DEFAULT 1

但要注意：默认值只对"未显式指定该字段的INSERT语句"生效。如果你在代码里写了INSERT INTO dish (name, price) VALUES ('茶叶蛋', 2.00)，那status自动变成1；如果你写了INSERT INTO dish (name, price, status) VALUES ('茶叶蛋', 2.00, null)，那status是NULL而不是1。很多程序员容易在这一点上产生错觉，习惯性把默认值逻辑交给ORM去处理，其实SQL层面的DEFAULT语义就是这么规定的。

再比如orders.status默认值设为1（待接单），这样新订单进来就是待接单状态，代码里不用手动赋初值，少写一行是一行，还能避免漏赋值导致的NPE。

8.3 锁：并发下单时的表锁与行锁

面试常问MySQL锁的分类：全局锁、表级锁、行级锁；共享锁（S锁）、排他锁（X锁）；乐观锁、悲观锁。放在这个项目里最贴近的例子是"两个用户同时点同一碗粥"：

表级锁在MyISAM引擎下是全表锁——一个用户在改这碗粥的价格，其他用户连查看都阻塞。InnoDB用行锁解决这个问题。
行锁是InnoDB在索引项上加的锁。比如UPDATE dish SET price = 9.00 WHERE id = 2，只会锁住dish表里id=2这一行，其他粥品照样能查能改。
悲观锁：事务里先SELECT ... FOR UPDATE锁住记录，再执行UPDATE，适合更新冲突比较频繁的场景，但会导致并发度下降。下单时锁订单表防止重复操作就属于悲观锁。
乐观锁：不加锁，靠版本号或时间戳判断。UPDATE orders SET status = 2 WHERE id = ? AND status = 1，如果影响行数为0说明订单已被别人改过，冲突就交给业务处理。这个在"管理员接单"时非常实用——两个人同时点接单，只有一个人能成功，另一个人会拿到"该订单已被处理"的提示，而不是直接覆盖对方操作。

8.4 事务隔离级别与脏读

JDBC事务默认是"读已提交"或"可重复读"（取决于是MySQL默认隔离级别，InnoDB默认是"可重复读"）。在这个项目里，最可能被问到的场景是：下单读订单时会不会读到别人还没提交的数据？

答案是：默认隔离级别下不会。可重复读保证同一事务里多次SELECT结果一致，而READ COMMITTED保证读到的是已提交的数据，不会读到脏数据。JDBC可以通过conn.setTransactionIsolation()调整，但默认级别一般够用。这个点能在答辩时主动讲出来，会让老师觉得你是真理解了而不是背的。

9. 这个系统还可以怎么长：从JavaWeb到前后端分离的演进路线

做完成品之后，强烈建议你沿着一条线把它往前推进一步，既锻炼能力又能在答辩时秀一把。

第一步：抽出Service层。 把Servlet里的业务逻辑全挪到Service类里，Servlet只负责HTTP参数解析、调Service、结果分发。这样改一处逻辑不用满项目找。

第二步：引入JSON。 购物车加购、改数量这些高频操作改成返回JSON，前端用fetch或axios接收。JSP页面里引入jQuery或者原生fetch，渲染逻辑交给JS。这是从"服务端渲染"过渡到"前后端交互"的关键一步，做完这一步，你对JavaScript的理解会从"给按钮绑事件"上升到"处理接口数据"。

第三步：换成Spring Boot。 把DAO层从JDBC换成Spring的JdbcTemplate或者MyBatis，把Servlet换成Controller，把JSP换掉（如果走前后端分离就用Vue/React写页面，然后通过Nginx或Spring Boot的静态资源托管来部署）。每一步保持系统能跑，做完一步提交一个版本，整个过程你会非常清晰地看到"Spring Boot到底帮我解放了什么"——那些你手写过一遍的东西，到这一步全变成"哦，原来框架是在这里帮我把活干了"。

我自己带人做项目时经常说一句话："框架只是工具，基础认知才决定了你能走多远。" JSP+Servlet这个组合看起来朴素，但它把HTTP请求、会话管理、页面渲染、数据库事务这些Web开发的骨架全部摊开在你面前。这个早餐外卖管理系统做完之后，你的收获绝不仅仅是一份课程设计，而是对"网页请求到数据库再到网页返回"这条主链路的全盘理解。如果后面你想深入，可以再往里面加订单统计报表、用户积分、配送地址管理这些模块，每加一个模块都是对现有结构的一次考验，改着改着，你就有感觉了。

JSP+Servlet实战：早餐外卖管理系统（JavaWeb全栈项目）