企业官网建设流程全解析

简介：一份基于Web的网上订餐系统毕业设计论文资料，源自北方民族大学2014年学士学位论文，面向计算机科学与技术、软件工程等专业学生，可作为毕业设计选题与论文撰写的参考范本。内容以B/S架构为主线，系统论述了网上订餐系统的完整构建过程，包括技术经济与操作可行性分析、用户与管理员功能需求、用户信息与订单数据库设计、各功能模块编码实现及系统测试等环节，并覆盖用户注册登录、菜品浏览、购物车管理、在线下单、管理员接单配送、订单跟踪与服务评价等典型业务流程。资源为单个doc文档，共1个文件，压缩包约10.7MB，文档内包含中英文摘要、关键词、目录及正文，结构清晰便于查阅。目前已吸引931人学习下载，读者可从论文中获取需求分析的组织方法、数据库表结构设计思路、前后台功能模块划分方式及餐饮信息化系统的实现路径，对完成毕业设计或相关课程设计具有实际参考价值。

1. 网上订餐系统：为什么这个经典选题至今仍是课设常客

带学生做课设时，我见过太多网上订餐系统的翻车现场：演示时订单状态刷新不出来、购物车数据丢失、管理员收不到新订单提醒。问题往往不在代码量，而在订单状态流转、Session管理和消息推送这些细节上。网上订餐系统之所以被反复选作毕业设计和课程设计的题目，是因为它恰好覆盖了Web开发的核心知识点：B/S架构、用户与管理员双角色、购物车与订单状态机、数据库设计、消息推送机制。这篇方案将完整拆解从需求分析、数据库设计到模块实现和验收的整个流程，适合正在做同类毕设的学生直接参考，也适合需要快速搭建一个可演示原型系统的开发者借鉴。

2. 需求与可行性分析：从手工记录到在线订单的痛点拆解

在开始写代码之前，先把需求讲清楚。网上订餐系统的核心痛点非常明确：传统电话订餐需要餐厅手工记录订单信息，容易出错和遗漏；用户看不到餐品图片和价格，只能通过口头描述来点菜。系统要解决的，就是把整个流程数字化。

2.1 可行性分析：技术、经济、操作三维度的取舍

做可行性分析不是走过场，而是为后面的技术选型画边界。这个系统当年选型时做了一套完整的可行性判断，现在回头看依然值得借鉴。

技术可行性方面，Web开发平台加Java语言是当时的主流选择。相比PHP和ASP，Java的优势在于线程安全和高并发处理能力。JSP作为Sun公司在Java基础上开发的动态网页技术，用于餐品展示和页面渲染非常直接。前台用JSP展示数据，后台用Java处理业务逻辑，配合MySQL做数据存储，这个组合在技术栈成熟度、社区资料丰富度和学习曲线之间取得了平衡。特别是在2014年前后的技术环境下，JSP+Servlet+MySQL的搭配几乎成了Web课设的标准答案。

经济可行性方面，本系统对软硬件投入的要求都很低。MySQL和Tomcat都是开源免费的，Eclipse作为开发工具也是开源项目，开发者只需要一台普通计算机连接到网络就能完成整个开发和部署。对于餐饮业主来说，不需要增加额外硬件投资，也不需要购买商业软件授权，这是系统能被小餐饮商户接受的关键前提。

操作可行性是本系统的亮点。B/S架构带来最大的优势就是零安装——订餐者只需要一个浏览器，不需要下载任何客户端。任何人只要会用手机或电脑上网，就能完成浏览餐品、加入购物车、下单的全部操作。后台管理界面同样不需要培训，餐厅营业员登录后按提示就能处理订单。在做需求分析的时候，我通常会把“操作简便”作为一个硬性指标写入约束条件，而不是把它当作锦上添花的功能。

法律可行性和社会因素方面，系统本身不涉及任何侵权内容，餐品信息由餐厅自主维护，用户数据的使用范围仅限于系统内的订单处理。从社会效益角度，线上订餐代替电话手工记录，本身就是餐饮行业信息化建设的一部分，符合数字化经营的方向。

2.2 角色与用例分析：用户与管理员两条主线的边界划分

这个系统一共有两个核心角色：用户和餐厅管理员。用例设计时，我一般建议先画角色边界，再做用例细化，不然很容易出现功能归属不清、代码结构混乱的情况。

用户角色的用例覆盖了一条完整的订餐链路。注册和登录是入口，之后是浏览餐品信息、查询餐品、查看餐品详情，再往后是加入购物车、查看购物车、修改购物车中的商品数量、删除购物车商品、清空购物车，最后是确认订单、提交订单、查看订单、历史订单查询。订单完成后还有一个容易被漏掉的用例——服务评价。用户评价看似不起眼，但要在论文里形成完整的业务闭环，这个用例必须写进去。

管理员角色的用例集中在后台管理。新订单提醒是管理员最关心的功能，接收订单后要能查看订单详情，确认接单后更新订单状态，然后是配餐和配送的流程管理。餐品管理方面，管理员需要添加新餐品、修改餐品价格和描述、下架已售罄的餐品。销量统计分析也是管理员的用例之一，需要按时间段和餐品维度查看销售数据。在线客服功能可以归类到管理员用例，本质上是管理员对用户咨询的响应。

用例图画完之后，要检查一个关键问题——每个用例是否都能对应到具体的页面和操作。如果用例图画得很完整，但代码实现时发现某个用例没有对应的前端页面，说明需求分析和实际开发的衔接出了问题。

2.3 业务流程建模：订餐闭环中的关键活动图

流程建模阶段，我习惯用活动图把每个核心业务场景的流程画清楚，再动手写代码。这样做的好处是提前发现流程中的分支和异常处理点，比如登录失败怎么办、购物车为空时能不能下单、订单已经接单后用户能不能取消。这些分支逻辑如果在编码阶段才临时想，很容易漏掉边界条件。

整个系统的业务流程可以拆成五条主线。第一条是用户登录流程，从输入账号密码开始，经过账号验证、密码验证两个判断条件，验证通过后进入系统主页，失败则返回错误提示。第二条是订餐服务流程，这是系统的核心链路：用户浏览餐品列表，选择餐品加入购物车，查看购物车确认商品，确认订单信息后提交订单，订单进入待确认状态，管理员接单后配餐配送，用户确认收货后完成交易，最后对服务进行评价。第三条是历史订单查询流程，用户选择查询条件，系统从数据库检索订单数据并展示列表，用户点击任意订单可以查看明细。第四条是订单处理流程，这是管理员视角的主线，从接收新订单提醒开始，查看订单详情，确认接单，更新配送状态，最终完成订单。第五条是管理员管理流程，覆盖餐品管理、用户管理、销量统计等功能。

这五条主线图基本上确定了系统开发的主干逻辑，后续数据库设计和代码实现都围绕这几条主线展开。每条活动图上的关键节点，都要能在数据库表和数据流中找到对应的落点，这也是后续做数据库设计的依据。

2.4 系统开发环境选型说明

开发环境这块是很多学生在毕设论文里写不清楚的部分，这里把关键的选型逻辑说透。系统采用Java语言开发，构建在Eclipse集成开发环境上，运行于Tomcat服务器，数据库使用MySQL。开发过程中使用了JEECG快速开发平台来提升代码生成效率，减少重复的CRUD编码工作。需要特别说明的是Comet4j消息推送框架的选择——这是实现新订单实时提醒的关键组件。

Comet4j选择背后的考量其实很有意思。当时常见的Web实时通信方案有三种：传统的Ajax轮询、WebSocket推送、Comet长轮询。Ajax轮询实现简单但实时性差，服务器压力大；WebSocket虽然实时性好，但2014年前后的浏览器兼容性不够理想；Comet4j基于HTTP长连接机制，把浏览器与服务器之间的连接保持打开状态，当服务器端有新订单事件时，可以主动向下推送数据到管理员的浏览器页面。这个方案能够在不需要浏览器额外插件的情况下，实现近似实时的订单提醒效果，是当时技术条件下的合理选择。

3. 数据库设计：订单系统最容易被忽略的表设计细节

数据库设计是网上订餐系统最核心的环节之一。不少学生在这个环节翻车，原因是只关注了单个表的结构，忽略了表之间的关联关系、订单状态字段的设计和数据一致性的保障。这类系统的数据模型其实并不复杂，但订单和订单明细的关系、价格快照的存储策略、状态字段的枚举定义，这些细节决定了一个演示系统能不能承受真正的业务压力。

3.1 E-R模型与实体关系梳理

从需求分析可以提炼出系统的主要实体：用户、餐品、订单、订单明细、购物车、评论、管理员。实体之间的关系可以这样梳理：用户与订单是一对多关系，一个用户可以创建多个订单；订单与订单明细是一对多关系，一个订单包含多个餐品条目；餐品与订单明细是多对一关系，一个餐品可以出现在多个订单明细中，但为了保留历史快照，订单明细中要冗余存一份餐品名称和单价。购物车与用户是一对一关系，每个用户在同一时间只维护一个购物车。评论与订单是一对一关系，一个订单只能评价一次，避免刷评。

画E-R图时有一个容易被忽略的设计决策：购物车是否需要持久化存储。很多早期系统把购物车放在Session中，导致用户关闭浏览器或Session过期后购物车数据丢失。如果要把论文的数据模型做得更完整，我建议把购物车纳入数据库设计，这样订单模块和购物车模块可以共用一套用户与餐品的关联逻辑，也方便后期扩展“重新登录后购物车仍在”的体验优化。

3.2 核心数据表结构：用户表、餐品表、订单表

用户表是系统的基础表，重点设计唯一性约束和状态字段：

CREATE TABLE `user` ( `id` INT(11) NOT NULL AUTO_INCREMENT COMMENT '用户ID', `username` VARCHAR(50) NOT NULL COMMENT '用户名', `password` VARCHAR(100) NOT NULL COMMENT '密码', `phone` VARCHAR(20) DEFAULT NULL COMMENT '手机号', `address` VARCHAR(200) DEFAULT NULL COMMENT '收货地址', `email` VARCHAR(100) DEFAULT NULL COMMENT '邮箱', `register_time` DATETIME DEFAULT NULL COMMENT '注册时间', `status` TINYINT(4) DEFAULT '1' COMMENT '状态：1正常 0禁用', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='用户表';

用户名设置为唯一键非常关键。注册功能要判断用户名是否已存在，如果业务层代码里先查一遍再用，会存在并发注册的漏洞。直接用数据库唯一约束做兜底，插入时捕获DuplicateKeyException就能安全处理重复注册。密码字段的存储也要注意，至少用MD5加盐存储摘要，不要存明文。

餐品表设计时加入销量字段，这是为了方便做热卖餐品展示和销量排行：

CREATE TABLE `dish` ( `id` INT(11) NOT NULL AUTO_INCREMENT COMMENT '餐品ID', `name` VARCHAR(100) NOT NULL COMMENT '餐品名称', `category` VARCHAR(50) DEFAULT NULL COMMENT '餐品分类', `price` DECIMAL(10,2) NOT NULL COMMENT '单价', `description` TEXT COMMENT '餐品描述', `image` VARCHAR(200) DEFAULT NULL COMMENT '餐品图片路径', `sales_count` INT(11) DEFAULT '0' COMMENT '销量', `status` TINYINT(4) DEFAULT '1' COMMENT '状态：1上架 0下架', `create_time` DATETIME DEFAULT NULL COMMENT '创建时间', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='餐品表';

价格字段用DECIMAL(10,2)而不是FLOAT或DOUBLE，这是和经验教训有关的——浮点数在Java和MySQL中都有精度问题，金额相关的字段必须用定点数。餐品表和上架状态下架状态的配合，决定了用户端能否在菜单列表看到这个餐品，后台下架后，用户端应该从列表隐藏，但已生成的订单仍能显示快照信息。

订单主表是业务核心，状态字段的设计直接决定后续代码的复杂度：

CREATE TABLE `orders` ( `id` INT(11) NOT NULL AUTO_INCREMENT COMMENT '订单ID', `order_no` VARCHAR(32) NOT NULL COMMENT '订单编号', `user_id` INT(11) NOT NULL COMMENT '用户ID', `total_price` DECIMAL(10,2) NOT NULL COMMENT '订单总价', `status` TINYINT(4) DEFAULT '0' COMMENT '状态：0待确认 1已接单 2配送中 3已完成 4已取消', `remark` VARCHAR(200) DEFAULT NULL COMMENT '订单备注', `create_time` DATETIME DEFAULT NULL COMMENT '下单时间', `update_time` DATETIME DEFAULT NULL COMMENT '更新时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`), CONSTRAINT `fk_order_user` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='订单表';

订单编号独立成字段而不是直接用自增ID，原因在于业务上需要对用户展示订单号，也便于后续与外部配送平台对接。订单状态用TINYINT整数常量，用注释明确每个值代表的含义，这样比直接用字符串做状态判断更节省存储，也方便状态机做数值大小比较。

订单明细表设计时最重要的决策是快照：

CREATE TABLE `order_item` ( `id` INT(11) NOT NULL AUTO_INCREMENT COMMENT '明细ID', `order_id` INT(11) NOT NULL COMMENT '订单ID', `dish_id` INT(11) NOT NULL COMMENT '餐品ID', `dish_name` VARCHAR(100) NOT NULL COMMENT '餐品名称快照', `price` DECIMAL(10,2) NOT NULL COMMENT '下单时单价快照', `quantity` INT(11) NOT NULL COMMENT '数量', `subtotal` DECIMAL(10,2) NOT NULL COMMENT '小计金额', PRIMARY KEY (`id`), KEY `idx_order_id` (`order_id`), CONSTRAINT `fk_item_order` FOREIGN KEY (`order_id`) REFERENCES `orders` (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='订单明细表';

为什么明细表中要冗余dish_name和price？因为餐品表里的名称和价格是可以被管理员修改的。如果用户下单后管理员调整了餐品价格，历史订单里不应该跟着变化。快照的做法是“下单时把当日可见的信息复制一份到订单明细里”，这样即使餐品下架或改价，用户的订单详情仍然是下单时刻的真实状态。这个设计在答辩时主动讲出来，是加分项。

购物车表的设计如果选择持久化方案，需要关联用户和餐品，并记录数量和加入时间：

CREATE TABLE `cart_item` ( `id` INT(11) NOT NULL AUTO_INCREMENT COMMENT 'ID', `user_id` INT(11) NOT NULL COMMENT '用户ID', `dish_id` INT(11) NOT NULL COMMENT '餐品ID', `quantity` INT(11) NOT NULL DEFAULT '1' COMMENT '数量', `create_time` DATETIME DEFAULT NULL COMMENT '加入时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_user_dish` (`user_id`, `dish_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='购物车表';

唯一约束uk_user_dish的作用是同一种餐品不会在同一个用户的购物车中产生多条记录，数量直接累加即可。

3.3 数据一致性保障的策略

订单表中的状态流转必须由统一的服务层控制。不允许在JSP页面里直接写SQL去修改订单状态，这样会绕过所有业务校验，产生数据不一致的隐患。通常的做法是在Service层提供一个updateOrderStatus方法，方法内部先校验当前状态和目标状态是否满足流转规则，满足才执行更新。

订单提交的跨表操作要放在同一个事务里。用户提交订单时涉及三个数据动作：插入订单主表记录、批量插入订单明细记录、清空购物车。这三步必须保证原子性——任何一步失败，之前的写入都应该回滚。在Java中使用JDBC事务管理时，可以显式调用Connection的setAutoCommit(false)，业务逻辑完成后commit，异常时rollback。如果使用了Spring框架，可以用@Transactional注解来声明事务边界，配置更简洁。

销量统计字段update采用原子操作，避免并发超卖问题：

UPDATE dish SET sales_count = sales_count + 1 WHERE id = ?

而不是先查询出当前值再加一写回。原因是并发环境下两个请求同时读到相同销量值，分别加一写回，最终销量只增加了一次而不是两次。直接用SQL的原子自增，可以把并发问题抛给数据库锁机制去解决，这是最省代码也最安全的做法。

4. 总体架构与模块实现：JSP+Servlet+MySQL经典组合的落地

系统架构决定了代码的组织方式，也决定了答辩时你能把系统讲得多清楚。网上订餐系统最合适的架构是B/S三层结构：表示层用JSP，业务逻辑层用Servlet和JavaBean，数据访问层用DAO模式。三层各司其职，职责边界清晰，这也是课设论文里最容易讲清楚、老师最容易认可的结构。

4.1 三层架构的职责划分与部署视图

表示层只做两件事：接收用户请求、渲染页面数据。JSP页面通过表单或Ajax向Servlet提交请求，Servlet调用业务层处理数据，处理完成后请求转发到JSP页面展示结果。业务逻辑层承载系统核心规则，包括订单状态机、价格计算、购物车操作、用户权限验证。数据访问层通过DAO类封装所有JDBC操作，Service层不直接写SQL，统一通过DAO接口访问数据库。

实际部署时使用Tomcat作为Servlet容器，MySQL作为存储，浏览器端无需安装任何插件。这种部署方式的最大价值在于开发和维护成本低，做课设或者小型餐饮商户使用足够。需要扩展时，只要保证层与层之间的接口不变，替换某层的实现方式不会影响其他层。

4.2 用户注册登录：安全细节与状态管理

注册和登录是系统的入口，也是答辩时老师最喜欢问的地方。注册页面的表单提交到RegisterServlet后，业务层需要完成以下逻辑：检查用户名是否已存在，校验手机号格式，校验密码长度，密码加密存储，插入用户记录。每一步校验失败都要返回到注册页面并显示对应的错误提示。

登录逻辑的核心是Session状态管理。登录成功后，需要在Session中保存用户ID、用户名、用户角色等信息。用户访问需要登录的页面时，通过过滤器拦截请求检查Session中是否有用户信息，没有则重定向到登录页面。退出登录时要同时销毁Session中的用户属性和购物车数据，避免出现二次登录时数据串号。

JSP注册页面的一个示例片段：

<form action="register" method="post"> <div> <label>用户名</label> <input type="text" name="username" required maxlength="50"/> </div> <div> <label>密码</label> <input type="password" name="password" required maxlength="50"/> </div> <div> <label>手机号</label> <input type="text" name="phone" required maxlength="11"/> </div> <div> <label>收货地址</label> <input type="text" name="address" maxlength="200"/> </div> <button type="submit">注册</button> </form>

registerServlet的核心处理逻辑可以简化为：调用userService.register方法，方法内部先判断username是否存在，密码用MD5加盐处理后写入数据库。返回结果封装成一个消息对象，如果成功则重定向到登录页，失败则携带错误信息返回注册页。用户输入校验放在服务层而不是JS层，JS校验只是提升体验，服务层校验才是安全底线。

4.3 购物车模块：Session方案与代码实现

购物车模块是用户和订单之间的桥梁。系统在实现时采用Session中维护购物车对象的方式，配合用户的登录状态使用。购物车数据模型用Map<餐品ID, CartItem>结构，每次操作购物车时通过餐品ID快速定位条目，增删改的复杂度都是常数级别，响应速度快。

加购逻辑的核心代码：

public class Cart { private Map<Integer, CartItem> items = new HashMap<>(); public void addDish(Dish dish, int quantity) { if (items.containsKey(dish.getId())) { CartItem item = items.get(dish.getId()); item.setQuantity(item.getQuantity() + quantity); } else { CartItem newItem = new CartItem(dish, quantity); items.put(dish.getId(), newItem); } } public void removeDish(int dishId) { items.remove(dishId); } public void updateQuantity(int dishId, int quantity) { CartItem item = items.get(dishId); if (item != null) { item.setQuantity(quantity); } } public BigDecimal getTotalPrice() { BigDecimal total = BigDecimal.ZERO; for (CartItem item : items.values()) { total = total.add(item.getSubtotal()); } return total; } }

CartItem对象保存餐品ID、名称、单价、数量，通过getSubtotal方法计算小计。整个设计读起来一目了然，答辩时能直接讲清楚购物车的数据结构和操作逻辑。需要说明的一点是，购物车计算总价时必须使用BigDecimal，避免浮点运算产生的金额误差。用户修改购物车商品数量时应限制上限，防止负数或超大值进入数量字段，这个校验同样放在Service层做。

4.4 订单提交：事务控制和状态机设计

订单提交是整个系统最复杂的业务流程。用户在购物车页面点击提交订单后，OrderService需要完成以下连续操作：生成唯一订单编号，计算总价，如需检查餐品状态则确认所有餐品均为上架状态，插入订单主表记录，批量插入订单明细记录，清空购物车。这组操作必须被放进同一个数据库事务中，任何一步失败都要整体回滚。

订单状态机定义五个状态，流转方向有清晰规则：待确认可以流转为已接单或已取消；已接单可以流转为配送中；配送中只能流转为已完成；已完成是终态；已取消是终态。管理员在后台的操作触发状态变更，用户取消订单只能在待确认状态时进行。OrderService中的updateOrderStatus方法会在更新前检查合法性。

订单提交完成后还有一个重要动作——触发管理员端的新订单实时提醒。这通过Comet4j消息推送实现。用户端提交订单成功后，服务端在完成事务提交后向管理员端推送新订单消息，消息内容包含订单编号和总价。管理员页面收到推送后弹出提示，不需要手动刷新浏览器就能感知新订单的到达。

4.5 销量统计与热卖餐品展示

销量统计功能需要两个维度的数据产出。第一个维度是热卖餐品排名，要求按照销量倒序展示前10个餐品，用于用户主页的热卖区域展示。第二个维度是管理员端的统计报表，需要按时间段展示订单量和销售额。

热卖餐品的SQL查询非常简单，关键在索引优化：

SELECT dish_id, dish_name, SUM(quantity) AS total_sales FROM order_item WHERE create_time >= NOW() - INTERVAL 7 DAY GROUP BY dish_id ORDER BY total_sales DESC LIMIT 10;

ORDER BY配合LIMIT的写法必须存在索引可行的前提上。order_item表的create_time字段是筛选条件，如果表数据量大，这个查询要在create_time上建索引，否则全表扫描会拖慢首页加载。答辩时可以提一句统计周期和索引设计，这个细节能体现数据库优化意识。

4.6 在线客服与消息推送机制

在线客服是系统的增值功能。在传统订餐场景中，用户对餐品有疑问时只能打电话询问，效率很低。在系统实现中，客服模块可以基于Comet4j消息推送做一个简单的在线聊天窗口，用户发消息后管理员端实时收到并在后台回复，回复内容通过推送回传到用户页面。

Comet4j的前端引擎在页面中建立一个长连接，回调函数绑定在消息接收事件上。用户端客服页面代码如下：

engine.listen('reply', function(msg) { var content = document.getElementById('chatContent'); content.innerHTML += '<div>客服回复：' + msg + '</div>'; });

后端通过Comet4j的HTTP通道调用推送方法，向指定频道发送消息。这里需要注意的一个坑是，Comet4j的长连接在代理服务器环境中容易被主动断开，我在开发的避坑章节会详细展开重连机制的实现。

5. 网上订餐系统避坑指南：从部署到调试的常见问题排查

做这套系统时踩过的坑不少，这里挑五个最容易在开发中翻车的问题，按“现象—原因—解决”的方式展开。这些问题不是网络搜来的理论，都是实际开发时会遇到的真实场景，处理方案可以直接照搬。

5.1 中文乱码：JSP页面到数据库的编码链路

现象：JSP页面里的中文正常显示，但数据库里存进去之后变成乱码，或者反过来，数据库里的中文读出来在页面上显示为问号。

原因：JSP页面编码、HTTP请求编码、数据库连接编码、MySQL表字符集，这四个环节只要有一个不一致就会出现乱码。最常见的情况是JSP设置了UTF-8，但JDBC连接串没有指定characterEncoding参数，MySQL连接默认用了iso-8859-1，导致写入时编码被转换。

解决：多维度统一编码。JSP页面顶部全部使用UTF-8。web.xml中配置一个CharacterEncodingFilter，统一处理请求和响应的编码。JDBC连接串追加useUnicode=true和characterEncoding=utf-8两个参数。数据库表创建时指定DEFAULT CHARSET=utf8。注意修改已有表时，要对数据本身做一次转码，不要直接改表结构，否则旧数据可能全变乱码。

5.2 购物车Session丢失：刷新页面后购物车清空

现象：用户将餐品加入购物车后，点击详情页或刷新页面再返回，购物车显示为空。

原因：一般有三种可能。服务器重启导致Session内存数据丢失；Session超时导致失效；浏览器在跳转过程中新建了会话。如果购物车对象被存入Session后，某次请求意外调用了session.invalidate方法，同样会导致数据清空。

解决：最彻底的做法就是把购物车持久化到数据库，每次加购操作同步更新数据库记录。如果时间紧张只能基于Session，至少做到两点：确保购物车对象在登录时初始化，不要在跳转过程中手动销毁Session；给Session设置合适的超时时间，不建议超过30分钟。我的建议是直接采用数据库存储方案，虽然多写两张表，但稳定性和答辩分数都值得这个投入。

5.3 订单并发：多人同时下单销量不准确

现象：多个测试账号同时提交包含同一餐品的订单，最终销量统计数量小于实际订单中的餐品总数。

原因：典型的并发写竞争。销量更新操作如果写成“先SELECT当前销量，计算加一，再UPDATE写回”这样的三步操作，两个请求同时执行时会读到相同的初始值，后写的覆盖先写的，销量最终只增加了一次。

解决：改用数据库原子自增。UPDATE dish SET sales_count = sales_count + 1 WHERE id = ? 直接把加一操作交给数据库锁机制处理，不需要显式加锁。订单主表和明细表插入操作同样有并发问题，跨表写入必须用事务包裹，确保主表插入失败时明细表不会成为孤儿数据。

5.4 数据库连接泄漏：系统越跑越慢

现象：系统刚部署时响应正常，连续运行几个小时后页面加载越来越慢，最终Tomcat日志报出连接获取超时。

原因：DAO层的数据库操作获取了Connection，但在方法结束时没有调用close释放。更隐蔽的一种是Statement和ResultSet也没有关闭，它们占用的数据库资源不会被GC自动回收。每次请求泄漏一个连接，几十个请求下来连接池就空了。

解决：使用统一的BaseDAO工具类封装连接获取和释放，在finally块中保证连接、Statement、ResultSet全部关闭。养成在每个方法结束后自查的习惯：有没有从连接池拿连接，拿到之后有没有释放。使用连接池后，程序中的close实际上是归还连接到池，而不是真正关闭，所以写close代码不会带来性能损耗，放心写。

5.5 Comet4j推送连接断开后无法恢复

现象：管理员端新订单提醒一开始正常，运行一段时间后就不再弹出，刷新页面后一切恢复正常。

原因：Comet4j基于HTTP长连接，长时间不通信时，代理服务器、路由器或Tomcat自身的连接超时机制都会主动断开这条连接。连接断开后前端引擎没有机制感知，也没有自动重建连接，因此推送功能在静默中失效。

解决：前端加入心跳检测和自动重连机制。设定定时器间隔30秒发送一次心跳请求，如果超过三个心跳周期没有收到服务端响应，判定连接已断开，调用初始化方法重新建立连接。还要在所有页面加载时主动注册连接，确保切页面后推送仍然有效。自动重连逻辑写成通用函数，在线客服和订单提醒共用同一套实现。

6. 系统测试与答辩准备：用可验证的指标证明系统能用

6.1 核心流程测试用例表

测试不能只看“能跑不能跑”，要按功能模块和业务流程设计用例，覆盖正常路径和异常路径。以下是这套系统验收时必须覆盖的测试用例：

正常路径的测试用例全部通过后，还要跑一遍异常路径：登录时连续五次输错密码，购物车中加入不存在的餐品ID，提交订单时人为中断数据库连接，确认这些场景都不会产生脏数据。

6.2 答辩演示动线与提问准备

答辩演示的动线设计比代码本身更能影响最终分数。演示时要按故事线来走，不要功能点式跳跃，让评委跟着完整业务流程看下来。我建议的顺序是：注册新用户，突出账号密码校验的交互提示；登录后浏览餐品列表和热卖餐品展示，说明数据来自真实数据库查询；加购两个不同餐品，修改其中一个数量，展示购物车的动态汇总；提交订单，此时切换屏幕展示管理员端收到实时推送，这一步是系统的亮点；管理员接单并更新状态，切回用户端确认状态同步；进入订单列表演示历史订单查询；最后演示销量统计页面，关联订单数据讲清楚SQL逻辑。

答辩中几乎必问的几个问题要提前准备：为什么选B/S架构，重点讲浏览器免安装跨平台和集中化部署的优势；购物车为什么用Session而不用数据库，为这个设计决策想好辩护理由，如果用了数据库方案，讲清楚与Session方案的区别和改进点；订单状态如何保证一致性，从状态机设计和事务控制两个角度回答；系统有什么可扩展性，提出Redis缓存、分布式部署、微信小程序入口、在线支付接入这些升级方向。每个问题回答控制在两分钟以内，先说结论再展开细节。

6.3 答辩前必须走完的一遍全流程

答辩前一天晚上，强制自己走一遍完整的用户生命周期：从注册开始，到登录、浏览、加购、修改数量、提交订单、登录管理员端接单、更新配送状态、完成订单、发表评价，全过程不允许跳过任何一步。特别是订单状态相关的所有路径——确认、接单、配送、完成，每一状态变更都要在用户端和管理员端交叉验证。这套检查方法是我被坑过一次之后才养成的习惯：曾经有个学生在答辩现场，管理员端接单后用户端的订单状态始终不变，查了很久发现是JSP页面缓存了旧数据，因为页面用了浏览器缓存。从那以后我每次做系统项目，交付前都会完整走一遍核心链路，确认没有任何一个环节依赖“手动刷新才能生效”的隐含条件。希望这篇方案能帮你在做网上订餐系统时少踩几个坑，答辩顺利。

本文还有配套的精品资源，点击获取