JavaWeb餐厅管理系统开发：业务梳理与核心技术实现

1. 餐厅管理系统到底在管什么：先搞懂业务流程再动手

很多初学者拿到“基于JavaWeb的餐厅管理系统”这类题目，第一反应就是打开IDE建表写代码。如果你也是这么干的，那么恭喜你，你大概率会在写了一半之后推倒重来。我做这个项目的时候踩过这个坑，所以想先和你聊聊：在写第一行Java代码之前，到底应该想清楚什么。

餐厅管理系统本质上是一套面向线下餐饮场景的信息化工具。它的核心不是“管理饭菜”，而是管理餐厅运营中的三件事：人（服务员、收银员、后厨、顾客）、物（菜品、桌台、库存）和钱（订单、结算、账单）。只要把这三条线理清楚，系统的功能模块、数据库表结构、甚至Servlet的跳转路径，都会自己浮出水面。

我见过不少同学的课程设计，把系统做成了“增删改查大礼包”——菜品可以增删改查、用户可以增删改查、订单可以增删改查，但页面之间没有业务逻辑串联。这样的系统交给老师答辩，一问“用户下单之后，后厨怎么看到订单？”就答不上来。这就是因为没有先梳理业务流程。

真实的餐厅运营流程大概是这样的：

1. 顾客进店，服务员安排桌台；
2. 顾客浏览菜单（纸质菜单或电子菜单），服务员记录所点菜品；
3. 点餐信息传递到后厨，后厨按单制作；
4. 菜品制作完成后上菜；
5. 顾客用餐过程中可能加菜、退菜；
6. 用餐结束，收银员根据订单汇总金额，顾客结账（现金、扫码、会员卡等）；
7. 结账完成后桌台清空，可以接待下一批顾客。

这个流程看似简单，但放到系统里就有很多需要设计的细节。比如：点餐时如果一个桌台已经点了5个菜，其中3个已经上菜，这时再加2个菜，订单怎么处理？结账时是整单结还是可以分单结？这些都直接影响订单表、订单明细表的状态字段怎么设计。

我当时的做法是：先用思维导图把角色和功能梳理出来，再画流程图确认状态流转，最后才开始建表。整个过程看起来慢了，但实际写代码的时候几乎没有返工。

提示：课程设计和毕业设计最核心的评分点通常不是功能多炫酷，而是“逻辑自洽、流程完整”。宁可少做几个花哨功能，也要把核心业务链路做通。

1.1 系统角色拆分：谁能做什么必须提前定死

餐厅管理系统的角色一般分为：管理员（老板）、收银员、服务员、后厨，有的还有会员。每个角色看到的界面和能做的操作完全不同。

管理员管的是“宏观数据”：菜品信息的维护（上架、下架、改价）、桌台信息的维护、员工账号的开通与冻结、每日营业额的统计。收银员管的是“钱”：结账、退款、打印小票、查看当日流水。服务员管的是“操作”：开台、点餐、加菜、退菜、确认上菜。后厨管的是“执行”：查看待制作的订单、标记完成。

有人会觉得，服务员和后厨都用一个账号不就行了？省事。但在真实项目里这是大忌。角色权限的分离不仅仅是为了“安全”，更重要的是让每个环节有迹可循。后厨看到的是“菜品维度”的订单（第3号桌：宫保鸡丁x1、米饭x2），服务员看到的是“桌台维度”的订单（第3号桌，合计金额58元），两者关注的数据完全不同。

在JavaWeb阶段，实现角色权限控制最直接的方式就是Filter过滤器+Session。用户登录成功后把角色标识存到Session里，写一个过滤器拦截所有请求，根据请求URL前缀或参数判断当前角色是否有权限访问。

java复制// 简单的角色判断逻辑
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
    HttpServletRequest req = (HttpServletRequest) request;
    HttpSession session = req.getSession();
    String role = (String) session.getAttribute("role");
    String path = req.getRequestURI();
    
    if (path.contains("/admin/") && !"admin".equals(role)) {
        // 没有管理员权限，跳转到错误页或登录页
        req.getRequestDispatcher("/login.jsp").forward(request, response);
        return;
    }
    chain.doFilter(request, response);
}

1.2 功能清单与优先级排序

把角色理清之后，功能清单基本就成型了。我当时列了一个表格，按“必做”、“选做”、“加分项”分级：

这个优先级顺序很重要。我做项目的时候先按这个顺序把必做功能全部跑通，再回头加选做和加分项。很多同学的习惯是从第一个功能开始精雕细琢，结果做到订单模块时发现时间不够，只能草草收场。项目开发最忌讳的是线性推进，而应该按依赖关系推进：先打通主干链路，再丰富分支细节。

2. 技术选型与分层设计：为什么用这些技术组合

说实话，2024年的生产环境已经很少直接裸写Servlet和JSP了，大家都用Spring Boot。但课程设计选择JavaWeb（JSP+Servlet）这个技术栈，我觉得有几个非常务实的理由：

第一，这个方案能让你把HTTP请求的底层流转机制看得清清楚楚。Spring Boot把Tomcat、DispatcherServlet、视图解析器都封装好了，你写的时候很爽，但出了问题往往一头雾水。用Servlet你亲手写了doGet、doPost，亲手配了web.xml，你会真正理解一次浏览器请求是怎么到达后端代码的。

第二，这个方案部署简单，答辩演示出问题的概率低。一个打包好的WAR包扔进Tomcat的webapps目录就能跑，不需要配复杂的Maven多模块工程。对于课程设计来说，稳定比先进重要。

第三，JSP+Servlet的组合在数据渲染上有天然优势。菜品列表、订单详情这类页面，直接用JSP的<c:forEach>标签结合EL表达式就能把后端数据渲染到HTML上，不需要单独写JSON接口和前端渲染代码，对非前端专业的学生友好得多。

2.1 三层架构在项目里怎么落地

JavaWeb课程的老师一定会反复强调“三层架构”：表现层、业务层、数据访问层。但很多同学写代码的时候还是习惯把所有逻辑堆在Servlet里，一个类一千多行，结果越写越乱。这个项目我建议你严格按照包结构来约束自己：

code复制com.restaurant
 ├── controller      // Servlet层，相当于MVC中的C
 ├── service         // 业务逻辑层，处理具体业务规则
 │    └── impl
 ├── dao             // 数据访问层，负责与数据库交互
 │    └── impl
 ├── entity          // 实体类，对应数据库表
 ├── filter          // 过滤器，权限控制、编码处理
 └── util            // 工具类，数据库连接池、字符串处理等

各层之间的调用关系是单向的：JSP页面发请求到Servlet，Servlet调用Service接口，Service的实现类里写业务逻辑，需要数据时调用Dao接口，Dao的实现类用JDBC或MyBatis操作数据库。比如点餐这个操作：

• Servlet接收请求中的桌台ID和菜品ID列表；
• Service层先校验桌台状态是否为空闲，再校验菜品是否都处于上架状态；
• Service层开启事务，先插入订单记录，再插入订单明细记录，同时把桌台状态改为占用；
• 事务提交。

这个过程中，Servlet层只负责“接收参数、调用Service、转发页面”，代码非常薄。业务规则（比如桌台状态校验、菜品上下架校验）全部沉淀在Service层。这样做的最大好处是：如果其他地方也要用“点餐”这个功能（比如服务员端和收银员端都能点餐），只需要复用同一个Service方法，不会出现逻辑不一致。

我当时写代码已经写到了订单模块，才彻底理解了“分层”的意义。之前总觉得分层是浪费时间：一个简单的查询，绕四个包多累！但一旦有了改动需求，比如点餐时要检查库存数量，你只需要改Service层的一个方法，而不是去所有相关的Servlet里翻找SQL。这种“可维护性”的体验，真的只有自己动手写一个完整项目才能感受到。

2.2 数据库连接：别再用DriverManager硬编码连接

有一件事我希望你能避免：在每个Dao类里用DriverManager.getConnection(url, user, password)去连数据库。不是说你不能这么干，而是这么干之后会遇到两个烦人的问题：

第一，数据库连接是昂贵的资源。每次创建和销毁一个Connection，底层都要经过TCP握手、MySQL认证、清理资源等一系列操作。在高并发场景下（别觉得餐厅系统没有高并发，饭点的时候几十个人同时下单很常见），频繁创建连接会导致响应延迟明显。

第二，连接信息散落在代码各处。一旦数据库密码改了，你要打开十个Java文件逐个修改，漏一个就出bug。

我当时的做法是使用C3P0连接池，它的配置非常简单，只需要一个XML配置文件。虽然现在更常用的是Druid或HikariCP，但C3P0的技术含量足够应付课程设计，而且很多教材都讲它，答辩老师也熟悉。

xml复制<c3p0-config>
    <default-config>
        <property name="jdbcUrl">jdbc:mysql://localhost:3306/restaurant_db?useSSL=false&amp;serverTimezone=Asia/Shanghai</property>
        <property name="user">root</property>
        <property name="password">123456</property>
        <property name="initialPoolSize">5</property>
        <property name="maxPoolSize">20</property>
        <property name="checkoutTimeout">3000</property>
    </default-config>
</c3p0-config>

然后写一个工具类，整个项目统一从这里获取连接：

java复制public class DBUtil {
    private static ComboPooledDataSource dataSource;
    static {
        try {
            dataSource = new ComboPooledDataSource();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
    public static Connection getConnection() throws SQLException {
        return dataSource.getConnection();
    }
    public static void close(Connection conn, PreparedStatement ps, ResultSet rs) {
        if (rs != null) { try { rs.close(); } catch (SQLException e) { e.printStackTrace(); } }
        if (ps != null) { try { ps.close(); } catch (SQLException e) { e.printStackTrace(); } }
        if (conn != null) { try { conn.close(); } catch (SQLException e) { e.printStackTrace(); } }
    }
}

注意close方法的细节：关闭资源的顺序是ResultSet先关，再PreparedStatement，最后Connection。如果直接关Connection，某些驱动下会导致ResultSet和Statement的资源残留。

提示：连接池里的conn.close()并不是真的关闭连接，而是把连接归还给连接池复用。所以多次调用close方法不会报错，但如果你没有调用close，那么这一条连接会一直被占用，连接池连接耗尽后系统就会假死。

3. 数据库设计：这6张核心表决定了系统的天花板

餐厅管理系统的数据库设计是整个项目的灵魂。表结构设计得好，后面写SQL、写Java代码都顺风顺水；设计得不好，后期加个功能得改表结构、改实体类、改Dao层，牵一发动全身。我前前后后设计了三版表结构，最后沉淀下来6张核心表。

3.1 六张核心表的字段设计与关系

第一张是用户表（t_user），存放系统登录账号信息：

sql复制CREATE TABLE t_user (
    id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(50) NOT NULL UNIQUE,
    password VARCHAR(100) NOT NULL,
    real_name VARCHAR(50),
    role VARCHAR(20) NOT NULL DEFAULT 'waiter',
    phone VARCHAR(20),
    status TINYINT DEFAULT 1 COMMENT '1启用，0禁用',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);

这里的role字段可取admin、cashier、waiter、kitchen四种值，对应管理员、收银员、服务员、后厨。status字段用来软禁用账号，删除用户会造成历史数据关联问题，所以设计系统时优先考虑“禁用”而不是“删除”。

第二张是菜品分类表（t_category）：

sql复制CREATE TABLE t_category (
    id INT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(50) NOT NULL,
    sort_order INT DEFAULT 0,
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);

分类表看似简单，但它和菜品表就是典型的一对多关系。热菜、凉菜、汤品、主食、饮品，每个分类下包含多个菜品。分类表的意义在于前端页面能按分类分组展示菜品，后厨也能按分类快速定位。

第三张是菜品表（t_dish）：

sql复制CREATE TABLE t_dish (
    id INT PRIMARY KEY AUTO_INCREMENT,
    category_id INT NOT NULL,
    name VARCHAR(100) NOT NULL,
    price DECIMAL(10,2) NOT NULL,
    image VARCHAR(255),
    description VARCHAR(255),
    status TINYINT DEFAULT 1 COMMENT '1上架，0下架',
    sales_count INT DEFAULT 0 COMMENT '累计销量',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (category_id) REFERENCES t_category(id)
);

注意这里的price字段我用的是DECIMAL(10,2)而不是FLOAT或者DOUBLE。这是个很关键的设计决定：浮点数在计算机中是近似存储的，0.1+0.2的结果是0.30000000000000004。如果涉及金额计算，用浮点类型会导致账目对不上的尴尬情况。DECIMAL是精确类型，专门用来存储金额。

第四张是桌台表（t_table）：

sql复制CREATE TABLE t_table (
    id INT PRIMARY KEY AUTO_INCREMENT,
    table_no VARCHAR(20) NOT NULL,
    capacity INT DEFAULT 4 COMMENT '可坐人数',
    status TINYINT DEFAULT 0 COMMENT '0空闲，1占用，2已结账待清理',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);

桌台状态是一个典型的“有限状态集合”，我用TINYINT存数字，在代码里定义常量来引用。有人会问为什么不直接用字符串“空闲”“占用”存进去，这样多直观。答案是：字符串状态容易写错（“空闲”和“空闭”就很难排查），而且占用存储空间更大。用数字枚举再加注释，在Java代码中定义常量，既规范又省空间。

第五张是订单表（t_order）：

sql复制CREATE TABLE t_order (
    id INT PRIMARY KEY AUTO_INCREMENT,
    order_no VARCHAR(32) NOT NULL COMMENT '订单编号',
    table_id INT NOT NULL,
    user_id INT COMMENT '操作员工ID',
    total_amount DECIMAL(10,2) DEFAULT 0.00,
    status TINYINT DEFAULT 0 COMMENT '0待制作，1制作中，2已上菜，3已结账，4已取消',
    remark VARCHAR(255) COMMENT '备注',
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP,
    pay_time DATETIME,
    FOREIGN KEY (table_id) REFERENCES t_table(id),
    FOREIGN KEY (user_id) REFERENCES t_user(id)
);

order_no字段是订单编号，用时间戳加随机数生成，比如20240515123045001。这里要注意：订单编号不能直接用自增主键id。因为订单号会打印在小票上、发给顾客，暴露订单总量和增长规律对餐厅来说不是好事。业务编号和主键id分开，是实际项目里非常常见的做法。

第六张是订单明细表（t_order_item），用来记录一张订单里具体点了哪些菜：

sql复制CREATE TABLE t_order_item (
    id INT PRIMARY KEY AUTO_INCREMENT,
    order_id INT NOT NULL,
    dish_id INT NOT NULL,
    dish_name VARCHAR(100) COMMENT '冗余菜品名称快照',
    price DECIMAL(10,2) COMMENT '冗余菜品单价快照',
    quantity INT DEFAULT 1,
    status TINYINT DEFAULT 0 COMMENT '0待制作，1制作中，2已上菜',
    FOREIGN KEY (order_id) REFERENCES t_order(id),
    FOREIGN KEY (dish_id) REFERENCES t_dish(id)
);

这个表是订单表和菜品表的关联中间表。为什么需要它？因为一张订单对应多个菜品，一个菜品也可以出现在多张订单中，这是典型的多对多关系。多对多关系在关系型数据库里必须拆成“订单表 + 订单明细表 + 菜品表”三张表。

dish_name和price这两个字段有一个重要的设计思想叫**“冗余字段”**。为什么订单明细里要存一份菜品的名称和价格，而不是直接关联菜品表去查询呢？因为菜品信息会变——今天宫保鸡丁卖28元，明天可能涨到32元。如果你不冗余，订单明细里的记录只能关联到菜品表的实时数据，那么历史订单的金额就会失真。而你在下单那一刻，把菜品的名称和单价复制一份到订单明细里，之后无论菜品表怎么改，历史订单的金额永远是正确的。

3.2 一个容易被忽视的设计：订单与桌台的解耦

在最早的设计里，我把订单表直接加了一个字段指向桌台，并在桌台表里也存了订单ID。后来发现这个设计是错的——如果一桌顾客点了两轮菜，结账时想分两单结（第一轮A请客，第二轮B请客），这个设计就无能为力了。

正确的做法是订单表里只存table_id，不存“当前订单ID”，桌台表也不存订单ID。通过table_id和status字段就能找到某个桌台的当前在用订单：WHERE table_id = ? AND status IN (0,1,2)。这样一张桌子即使有多张订单，也能通过状态字段区分哪些是历史订单、哪些是进行中的订单。

这种“解耦”的思想在系统设计中非常重要。表之间的关联越直接，后期扩展的灵活性就越差。你写课程设计的时候可能觉得没必要考虑这么复杂，但答辩时如果老师问“一桌两次点餐怎么处理”，你能答上来，这就是加分项。

4. 核心功能实现：从登录到结账的完整链路

数据库设计好之后，就可以开始写代码了。这一章我挑三个最能体现系统价值的功能展开讲：登录鉴权与权限拦截、点餐下单的事务处理、以及订单状态流转的设计。

4.1 登录鉴权：Session、Cookie和Filter的配合

登录功能每个做JavaWeb项目的同学都写过，但写出一个“能用的登录”和写一个“可维护的登录”差别很大。我用一个LoginServlet接收用户名密码，查询用户表校验，成功后把用户信息存进Session，然后跳转。

java复制@WebServlet("/login")
public class LoginServlet extends HttpServlet {
    private UserService userService = new UserServiceImpl();
    
    @Override
    protected void doPost(HttpServletRequest req, HttpServletResponse resp) 
            throws ServletException, IOException {
        String username = req.getParameter("username");
        String password = req.getParameter("password");
        // 实际项目中密码存储应使用MD5/SHA256加盐哈希
        User user = userService.login(username, password);
        if (user != null && user.getStatus() == 1) {
            HttpSession session = req.getSession();
            session.setAttribute("loginUser", user);
            // 根据角色跳转到不同页面
            String redirect = "/index.jsp";
            if ("admin".equals(user.getRole())) {
                redirect = "/admin/index.jsp";
            }
            resp.sendRedirect(req.getContextPath() + redirect);
        } else {
            req.setAttribute("errorMsg", "用户名或密码错误，或账号已被禁用");
            req.getRequestDispatcher("/login.jsp").forward(req, resp);
        }
    }
}

这里有两个细节值得说明。

第一，重定向与转发的选择。登录成功后我用的sendRedirect（重定向），登录失败后用的forward（转发）。重定向是浏览器重新发起一次新请求，地址栏会变化，可以防止表单重复提交——用户按F5刷新不会再次提交登录表单。转发是服务器内部跳转，浏览器不知道页面变化了，所以如果登录失败后转发到登录页，用户按F5就会重复提交表单。这个差异在真正的业务里非常重要。

第二，密码的存储方式。我在代码注释里写了“实际项目中密码存储应使用MD5/SHA256加盐哈希”。课程设计阶段很多人直接明文存密码，答辩时如果被问到“如果数据库泄露了怎么办”就会很尴尬。用MD5加盐其实代码量并不大：

java复制public static String md5WithSalt(String password, String salt) {
    String str = password + salt;
    try {
        MessageDigest md = MessageDigest.getInstance("MD5");
        byte[] digest = md.digest(str.getBytes(StandardCharsets.UTF_8));
        StringBuilder sb = new StringBuilder();
        for (byte b : digest) {
            sb.append(String.format("%02x", b));
        }
        return sb.toString();
    } catch (NoSuchAlgorithmException e) {
        throw new RuntimeException(e);
    }
}

注册用户时生成一个随机盐值存到用户表里，登录时用输入的密码加盐哈希，再和数据库存储的哈希值比对。这样即使数据库泄露，没有盐值也无法还原出原始密码。

登录之后的权限拦截，就是我在第一章提到过的Filter过滤器方案。把所有需要登录才能访问的请求路径用过滤器包住，在过滤器中检查Session是否有用户。

4.2 点餐下单：一个必须开启事务的核心操作

点餐是餐厅管理系统的核心操作，它涉及多张表的更新：插入订单记录、插入订单明细记录、更新桌台状态。这三步必须同时成功或者同时失败，不能出现“订单创建了但桌台还是空闲”的中间状态——这就是数据库事务的意义。

我用一个简单的JDBC事务来演示这个逻辑：

java复制public boolean createOrder(OrderVO orderVO) {
    Connection conn = null;
    try {
        conn = DBUtil.getConnection();
        conn.setAutoCommit(false);  // 开启事务，关闭自动提交
        
        // 1. 插入订单主表
        OrderService orderService = new OrderServiceImpl();
        int orderId = orderService.insertOrder(conn, orderVO);
        if (orderId <= 0) {
            conn.rollback();
            return false;
        }
        
        // 2. 批量插入订单明细
        boolean itemResult = orderItemDao.batchInsert(conn, orderVO.getItems(), orderId);
        if (!itemResult) {
            conn.rollback();
            return false;
        }
        
        // 3. 更新桌台状态为占用
        boolean tableResult = tableDao.updateStatus(conn, orderVO.getTableId(), 1);
        if (!tableResult) {
            conn.rollback();
            return false;
        }
        
        conn.commit();  // 提交事务
        return true;
    } catch (Exception e) {
        try {
            if (conn != null) conn.rollback();  // 异常时回滚
        } catch (SQLException ex) {
            ex.printStackTrace();
        }
        e.printStackTrace();
        return false;
    } finally {
        try {
            if (conn != null) conn.setAutoCommit(true);
        } catch (SQLException e) {
            e.printStackTrace();
        }
        DBUtil.close(conn, null, null);
    }
}

这里有一个需要特别注意的是事务边界的把握。事务不能开太大——如果你在事务里执行了一个耗时的HTTP请求或文件操作，那数据库连接会被长时间占用；但事务也不能开太小——如果你每个Dao方法都自动提交，就无法保证原子性。正确的做法是：一个业务操作（如点餐）对应一个事务，跨多个Dao操作，在Service层统一控制。

点餐的页面交互也有讲究。我当时做的是一个点餐页面，左侧显示桌台列表，点击某个空闲桌台后右侧显示菜品分类和菜品列表，勾选菜品，点击“下单”。前端用JavaScript维护一个“已点菜品”的JSON数组，提交时通过隐藏的文本域传给后端：

javascript复制function submitOrder() {
    var tableId = document.getElementById("tableId").value;
    var itemStr = JSON.stringify(cart.items);  // 将购物车数据序列化
    document.getElementById("orderItems").value = itemStr;
    document.getElementById("orderForm").submit();
}

后端用一个Json工具类（Jackson或Gson）解析这个JSON字符串，转换成订单明细的数据结构。这个做法不需要动态拼接HTML表单，也是实际项目里比较常见的做法。

4.3 订单状态机：如何设计一套不会乱套的状态流转

订单从创建到结账，状态是不断变化的。我设计的业务规则是：

• 待制作（0）：顾客下单后，后厨还没开始做；
• 制作中（1）：后厨接单，正在烹饪；
• 已上菜（2）：菜品端到顾客桌上，顾客正在用餐；
• 已结账（3）：顾客付款完成，订单结束；
• 已取消（4）：顾客撤销订单或超时未处理的单被取消。

状态流转是有严格方向的，不能随便跳转。比如一个“已结账”的订单不能退回“待制作”，这在业务上说不通。如果代码里没有做状态校验，后厨把“待制作”改成“已结账”也能成功，那系统就乱了。

我实现的方式是在Service层写一个状态更新的方法，只有合法的转换才会被接受：

java复制public boolean updateOrderStatus(int orderId, int targetStatus) {
    Order order = orderDao.findById(orderId);
    if (order == null) {
        return false;
    }
    int currentStatus = order.getStatus();
    Map<Integer, List<Integer>> statusFlow = new HashMap<>();
    statusFlow.put(0, Arrays.asList(1, 4));   // 待制作 -> 制作中 / 取消
    statusFlow.put(1, Arrays.asList(2, 4));   // 制作中 -> 已上菜 / 取消
    statusFlow.put(2, Arrays.asList(3));       // 已上菜 -> 已结账
    statusFlow.put(3, Collections.emptyList()); // 已结账是终态
    statusFlow.put(4, Collections.emptyList()); // 已取消也是终态
    
    List<Integer> allowedTargets = statusFlow.get(currentStatus);
    if (allowedTargets != null && allowedTargets.contains(targetStatus)) {
        return orderDao.updateStatus(orderId, targetStatus) > 0;
    }
    return false;
}

这种“状态机”的设计思路，用Map把合法的状态迁移关系预先定义好，只有符合规则的才能执行。它的好处在于：所有状态流转规则集中在同一个地方维护，其他地方的代码只要调用这个Service方法即可，不会出现散落的、互相矛盾的状态判断。

订单状态与桌台状态之间的联动也在这里处理：当订单状态变成“已结账”时，桌台状态应该从“占用”改为“待清理”或“空闲”。这需要在一个事务里完成，保证数据和数据之间的一致性。

5. 联调与部署时的高频问题：我的踩坑实录

代码写完不代表项目结束。从“能跑”到“稳定跑”，中间还隔着一堆让人头秃的问题。这里我按自己踩坑的先后顺序，把高频问题整理出来，希望你能少走弯路。

5.1 前端页面数据传不到后端的三种原因

做点餐和菜品管理功能的时候，我遇到过好几次“明明页面能看到数据，但一到后端就报空指针”的情况。排查了很长时间，发现原因各不相同：

第一种，表单控件的name属性缺失或写错。req.getParameter("dishName")拿到的永远是null，原因不是Java代码的问题，而是前端那个<input>标签没有写name="dishName"。这是新手最容易犯的错误——id是给JavaScript用的，name才是提交给后端的，两者不能混用。

第二种，提交方式与Servlet的do方法不匹配。表单method是get，Servlet里只写了doPost方法，结果请求404。Tomcat的日志里会提示类似HTTP method GET is not supported by this URL的错误。

第三种，复选框未选中时默认不提交。比如菜品管理中“是否上架”这个复选框，如果没勾选，浏览器根本不会把它的值提交给后端。后端拿到null之后转成int就会抛NumberFormatException。解决办法是在前端用一个隐藏域先提交默认值，或者后端的req.getParameter返回null时给一个默认值。

5.2 中文乱码的生命周期：从请求到响应

中文乱码是JavaWeb项目里最经典的问题。它的本质是字符编码不一致。如果你在浏览器页面看到中文正常，但存入数据库后变成问号，或者打开页面直接就是乱码，大概率是下面三个环节出了问题：

第一，请求编码。Tomcat默认使用ISO-8859-1解析请求体，而这个编码不支持中文。解决方法是加一个CharacterEncodingFilter，在请求进入Servlet前统一设置为UTF-8：

java复制@WebFilter("/*")
public class CharacterEncodingFilter implements Filter {
    @Override
    public void doFilter(ServletRequest req, ServletResponse resp, FilterChain chain) throws IOException, ServletException {
        req.setCharacterEncoding("UTF-8");
        resp.setContentType("text/html;charset=UTF-8");
        chain.doFilter(req, resp);
    }
}

第二，响应编码。如果你用resp.setContentType("text/html")而没指定charset，JSP页面可能按默认编码输出，导致页面中文乱码。每个JSP页面顶部都加上<%@ page contentType="text/html;charset=UTF-8" language="java" %>可以规避。

第三，数据库连接编码。即使请求和响应都正确，如果JDBC连接串里没指定编码，数据入库后依然可能乱码。所以在JDBC的URL里一定要加characterEncoding=utf8：

code复制jdbc:mysql://localhost:3306/restaurant_db?useSSL=false&characterEncoding=utf8&serverTimezone=Asia/Shanghai

这三个环节只要有一个不对，乱码就出来。排查乱码的思路就是“请求→服务器→数据库→响应”全程走一遍，看哪个环节的编码设置缺失。

5.3 分页查询与搜索：大量订单场景下的性能优化

餐厅运行一段时间后，订单数据会积累到成千上万条。如果订单管理页面一次性把全部订单查出来返回给前端，页面渲染会非常卡顿。分页查询就派上用场了。

分页的核心SQL是LIMIT offset, size。MySQL提供的这个语法可以从第offset条记录开始，取size条记录。用户请求第page页，每页显示pageSize条，那么offset = (page - 1) * pageSize。

分页的查询在JavaWeb项目里通常用PageUtil封装：

java复制public class PageResult<T> {
    private List<T> list;      // 当前页的数据
    private int pageNum;       // 当前页码
    private int pageSize;      // 每页条数
    private int totalCount;    // 总记录数
    private int totalPages;    // 总页数
    
    public PageResult(int pageNum, int pageSize, int totalCount, List<T> list) {
        this.pageNum = pageNum;
        this.pageSize = pageSize;
        this.totalCount = totalCount;
        this.list = list;
        this.totalPages = (int) Math.ceil((double) totalCount / pageSize);
    }
}

Dao层查询时，先用SELECT COUNT(*)查出总数，再执行带LIMIT的数据查询。这里要注意COUNT查询和列表查询是两次独立的查询，业务上允许它们有轻微的不一致（比如用户查询的同时有人下单），不会有太大问题。

提示：如果订单量特别大（比如百万级别），LIMIT offset, size在offset很大时性能会明显下降（MySQL要先扫描并丢弃前offset条记录）。更优的写法是WHERE id > ? LIMIT size，利用主键索引直接定位。不过课程设计阶段用不到这么极致，知道这个方向即可。

5.4 部署过程中的两个隐藏坑

项目开发完成后打包部署到Tomcat，有时候也会遇到坑。我印象比较深的有两个。

第一个是JAR包版本冲突。比如项目里同时用了老版本的commons-logging和新版本的log4j，可能会出现NoSuchMethodError这种非常诡异的错误。排查方式是逐个移除依赖JAR，或者统一用Maven管理依赖版本。如果你没用Maven，而是手动把JAR包扔进WEB-INF/lib目录，一定要记得检查是否有重复的同名JAR包，这是最常见的冲突来源。

第二个是静态资源路径404。项目里如果用相对路径写CSS和JS引用，比如href="css/style.css"，当当前URL路径深度不同时（/index.jsp和/admin/order/list），浏览器解析的相对路径完全不同，就会出现样式丢失。正确的做法是在JSP中动态获取项目根路径：

jsp复制<%
String basePath = request.getScheme() + "://" + request.getServerName() + ":" + request.getServerPort() 
    + request.getContextPath() + "/";
request.setAttribute("basePath", basePath);
%>

然后在引用资源的标签里写：

html复制<link rel="stylesheet" href="${basePath}css/style.css">

这样无论当前URL怎么变化，都能正确引用到项目根目录下的css文件。

6. 系统还能怎么加餐：四个面向答辩的进阶功能

如果核心功能全部跑通、时间还有富余，我会建议你从下面四个方向中挑一两个做扩展。这些功能难度适中，但非常能体现“系统设计思维”，在答辩时是很好的加分点。

6.1 图表统计：让数据说话

餐厅的管理者最关心的是：今天卖了多少？哪些菜最受欢迎？营业额和上周同期比较怎么样？这些都是数据可视化能回答的问题。

用ECharts在前端渲染一个柱状图或饼图，后端提供一个JSON接口返回统计结果。比如“菜品销量排行”的接口，SQL可以这么写：

sql复制SELECT d.name AS dishName, SUM(oi.quantity) AS totalQuantity
FROM t_order_item oi
JOIN t_dish d ON oi.dish_id = d.id
JOIN t_order o ON oi.order_id = o.id
WHERE o.status = 3 AND o.pay_time >= DATE_SUB(NOW(), INTERVAL 7 DAY)
GROUP BY d.id, d.name
ORDER BY totalQuantity DESC
LIMIT 10;

后端把查询结果封装成List<Map<String, Object>>，用Jackson转成JSON字符串，前端用JavaScript渲染到图表里。这个功能模块只占用一个Servlet、一个Service方法、一个查询SQL和一个HTML页面，工作量不大，但效果非常直观。

6.2 会员管理：消费积分的简单实现

会员表（t_member）可以存手机号、姓名、会员等级、累计积分、储值余额。点餐时可以按会员手机号识别身份，结账时享受折扣。如果做储值功能，涉及金额操作就更要谨慎，所有加钱减钱的操作都必须经过事务，避免数据不一致。

不过我会建议课程设计阶段不要碰“储值钱包”这类涉及资金安全的功能——涉及金额怎么记账、退款怎么处理、日志怎么留存，做深了工作量很大，做浅了答辩老师追问容易露怯。相比之下，“消费积分”这种简单逻辑更适合入门：每消费1元积1分，积分可以用来兑换菜品或抵扣现金。它的计算逻辑简单清晰，而且能体现“关联查询”的能力。

6.3 餐厅日志：记录每一次关键操作

日志是一个非常容易出彩的设计思路。谁在什么时间修改了哪个菜品的价格？谁在什么时间把订单状态改了？这些操作痕迹在真实系统中非常重要——出了问题能追溯到人。

不用引入复杂的日志框架，只需要一张t_operate_log表：

sql复制CREATE TABLE t_operate_log (
    id INT PRIMARY KEY AUTO_INCREMENT,
    user_id INT,
    username VARCHAR(50),
    operation VARCHAR(100),
    detail VARCHAR(255),
    create_time DATETIME DEFAULT CURRENT_TIMESTAMP
);

在Service层的关键方法（更新菜品、修改价格、取消订单等）中加一行日志记录调用。用Filter统一记录是个更优雅的方案，但要判断哪些请求需要记录，反而有点复杂。在核心Service方法里手动打日志，虽然是“笨办法”，但在课程设计里最直观。

6.4 移动端适配：让点餐页面在手机上能看

餐厅的系统除了收银台电脑，服务员手里可能拿着平板。如果时间充足，可以用CSS媒体查询做一套响应式布局，让点餐页面在窄屏下自动调整卡片排列。这不是一个独立功能，而是对已有页面的适配，改动量取决于你当年写页面时有没有考虑响应式。

如果不想折腾CSS，另一种做法是额外写一套“服务员简易点餐版”页面——极简列表，大字按钮，没有花哨的样式。这套页面不需要复杂的排版，用列表和按钮堆出来，反而更符合服务员快速操作的实际场景。对于JavaWeb项目，多一个页面就多一个功能入口，在演示时也更显得内容丰富。

7. 一些关于项目打磨的个人建议

做完这个餐厅管理系统，我最大的体会是：课程设计项目的核心价值不是“完成”，而是“把一整个业务链路走通”。从需求分析、表结构设计、代码分层、前后端联调，到最后的部署演示，每一步都会遇到具体的问题，而解决每一个问题的过程，就是经验积累的过程。

我记得有一次答辩演示时，现场网络不好，前端页面的ECharts图表加载不出来。当时很紧张，但老师反而问了一句“你的数据接口能直连调通吗？”我直接打开浏览器访问JSON接口，数据正常返回。老师点了点头说“前端出问题不影响后端，这是系统设计搭得好。”那一刻我才真正理解了分层设计的价值——它不只是让你的代码更好维护，更让你在面对环境变化时，系统的核心能力不被单点故障影响。

最后再分享一个小建议：做完项目后，把这套系统部署到云服务器上，用一个真实域名或IP地址访问一下试试。这个过程你会遇到服务器防火墙配置、数据库远程连接授权、Tomcat生产环境内存参数调整等一系列问题。这些问题平时在本地开发根本不会遇到，但它们正是真实开发环境中最常见的操作。哪怕课程设计答辩不需要线上演示，这些经验对你后续找实习、参加面试都会非常有帮助。

餐厅管理系统虽然是个经典的JavaWeb选题，但经典之所以经典，是因为它足够真实、足够复杂、又足够完整。认真做完，你会发现自己对Servlet、JSP、MySQL、事务、分页、状态机这些知识点的理解，都上了一层楼。