双技术栈在线订餐系统：SSM与Django共用MySQL的架构设计与实战

第一次把这个订餐管理系统完整跑通的时候，我的第一反应不是“终于能下单了”，而是“两套后端居然真的能在一张订单表上协作得这么干净”。这个系统本身其实就是典型的在线订餐业务：用户在小程序或者网页上浏览菜品、加购物车、下单支付，商家在后台接单出餐，平台管理员维护用户、菜品、订单和统计报表。但它有一个比较少见的技术组成——管理端和核心订单模块用 Java + SSM 实现，用户端接口服务用 Django 提供，两个后端共用一套 MySQL 数据库。正因为这种双栈设计，它一直都是课程设计里讨论度比较高的那类项目。

这套东西适合谁？一类是正在准备毕业设计或者课程设计的学生，想在一套系统里同时展示 Java 和 Python 两个技术栈的能力；另一类是刚入行的后端开发，想完整看一个业务系统从数据库建模、接口开发、前后端联调一直到部署上线的全过程。两边的难点其实不太一样：Java 那边重权限、重事务、重复杂查询，Django 这边重接口效率、重序列化、重并发控制。把这两条线拆开讲清楚，比单纯抄一份单栈代码要更有价值。

1. 一套订餐管理系统，为什么偏偏要用两套技术栈

1.1 先把订餐业务的闭环走一遍

很多第一次接触这个项目的人会问：一个订餐系统，有必要搞得这么复杂吗？我的看法是，先别急着判断技术选型，而是先把业务闭环走一遍，你会发现订餐系统天然就是多角色、多流程、多状态的典型业务系统。

整个闭环可以分成三段来看。第一段是用户侧：用户注册登录后，按分类查看餐厅和菜品，搜索某个菜品，加入购物车，确认收货地址，提交订单，然后支付。第二段是商家侧：商家收到新订单提醒，查看订单详情，接单，开始制作，出餐并呼叫配送。第三段是平台侧：管理员负责审核商家入驻，上架和下架菜品，处理用户投诉，查看每日订单量和营收统计，还要能处理退款和异常订单。

这三段不是孤立的。用户在手机上下单，这条记录会立刻出现在商家后台，同时也会出现在管理员的订单列表里。用户取消订单，商家的待处理列表要同步减少，库存要回补，运营报表里的取消订单数要增加。任何一个环节的数据不一致，都会直接影响用户体验。所以这个项目的核心并不在于页面好不好看，而在于这些状态之间能不能有序、准确地流转。

1.2 SSM 和 Django 各自该守哪半边

双栈方案的合理之处，在于它没有强行让两套框架做同一件事，而是按业务特征做了分工。

Java + SSM 这条线负责管理后台和核心交易模块，理由很简单：Spring 的事务管理非常成熟，MyBatis 写复杂查询很方便。管理后台天然需要处理大量结构化数据，比如订单列表的分页查询、多条件组合筛选、按日期汇总营收、导出报表，这些在 SSM 技术栈里都有非常成熟的方案。同时，管理后台涉及多级权限（超级管理员、运营管理员、商家管理员），SpringMVC 的拦截器配合 Session 做角色校验，逻辑清晰，也容易调试。

Django 这条线负责用户端接口，理由是开发效率高。用户侧的接口往往变化频繁，今天加一个推荐位，明天改一个优惠券展示逻辑，后天又要调整菜品列表的返回字段。Django 的 ORM 和 ModelSerializer 让这类迭代非常快。尤其是它自带的 Admin 后台，在开发期间可以用来快速维护测试数据，对前期开发帮助很大。

这里可以做一张简单的职责对照表：

1.3 为什么不统一技术栈：三个现实原因

很多人会下意识觉得一个项目应该统一技术栈，但实际开发里这种“混搭”并不少见。尤其是课程设计、毕业设计这类需要体现学习成果的项目，双栈反而有它的现实考量。

第一个原因是职责天然不同。C 端接口要求快速迭代和快速响应，Django 的轻量特性和 DRF（Django REST Framework）生态非常适合；B 端管理后台要求严谨的事务控制和稳定的权限体系，Java 的 Spring 生态是更稳妥的选择。把两套框架放在各自擅长的位置上，比强行统一成某一种技术栈更合理。

第二个原因是团队协作方式。如果是一个多人项目，前端有一个同学负责小程序和用户端页面，后端有两个同学分别负责用户端 API 和管理后台，那么“Django 出接口、SSM 管后台”的分工方式可以让两条开发线并行推进，互不阻塞。

第三个原因是学习价值。订餐系统虽然业务不复杂，但“同一套数据模型用两种框架实现”本身就是很好的对比练习。你在 Django 里用 ORM 写完一个购物车，再到 MyBatis 里写同样的 SQL，框架之间的设计差异会给你留下非常深刻的印象。

2. 数据库设计里的那些“不能省”的字段与订单状态机

2.1 六张核心业务表之间的关系

无论前端用的是什么框架，数据库设计始终是订餐系统最基础的部分。我习惯把整个系统的表分成两层：一层是基础数据表，一层是业务流程表。

基础数据表包括用户表、商户表、菜品分类表和菜品表。业务流程表包括购物车表、订单主表和订单明细表，另外还需要一张管理员表来支撑后台登录。这几张表之间的关系其实非常直观：一个用户对应多个订单，一个商户对应多个菜品，一个订单对应一个用户和一个商户，一个订单里可以包含多种菜品，所以订单主表和订单明细表是一对多的关系。

有一个设计点要特别说明，就是为什么要拆“订单主表”和“订单明细表”。订单主表存的是这次订单的整体信息，比如订单号、用户ID、商户ID、订单总金额、订单状态、下单时间。订单明细表存的是这个订单里每一道菜的信息，比如菜品ID、在购买那一刻的名称、单价、数量、小计金额。拆成两张表，是为了以后查询“某个订单买了哪些菜”时不用解析逗号拼接的字符串，也更符合关系数据库的范式。

我用一张表格把这六张核心表的关系整理一下：

2.2 订单状态机的五态流转

订餐系统里最容易出错的就是订单状态。用户在界面上的每一个操作，本质上都是在驱动订单状态发生变化。我把这套系统里的订单状态定义成六个值，覆盖从下单到完成的全部生命周期。

这里有一个很常见的坑：支付状态和订单状态必须分开存。我见过很多初版设计在订单表里只放一个 status 字段，结果“待支付时取消”和“已支付后退款”根本分不清。所以我坚持用 order_status 表示订单履约进度，用 pay_status 表示支付流水状态，两张状态各自独立，逻辑才不会乱。

超时未支付的处理也要在设计阶段想好。用户提交订单后如果一直不支付，菜品库存一直占着不放，对其他顾客不公平，所以需要一个定时任务，每分钟扫描一次创建时间超过 30 分钟且仍然处于待支付状态的订单，把状态改成已取消，同时把订单里占用的库存回补回去。这个功能看起来不起眼，但能给整个系统省掉大量客服沟通成本。

2.3 容易被忽略的字段设计细节

数据库字段设计会直接影响后面所有接口的写法，这里说几个我在这个项目里反复踩坑之后总结下来的细节。

价格字段必须用 DECIMAL(10, 2)，而不是 FLOAT。浮点数在计算机里是二进制近似表示，算总价的时候经常出现 19.999999 这种尴尬结果。DECIMAL 是精确小数，计算订单金额才能保证一分不差。

订单号不能直接用自增 ID 对外展示。用户投诉的时候，客服会问你订单号是多少，如果订单号是 12345，谁都无法快速定位。我用的方案是“日期 + 时间戳 + 随机数”拼接一个全局唯一的 order_no，这样只要看到订单号就能知道下单日期，排查问题省力很多。

所有业务表都建议加一个 delete_flag 字段做软删除。用户删除订单、商家下架菜品，都不要直接物理删除记录，而是把 delete_flag 置为 1。这样一方面可以防止误操作导致数据丢失，另一方面也为以后做数据统计留了余地。Django 端的 ORM 查询默认过滤 delete_flag=0，SSM 端在 MyBatis 的 SQL 里增加查询条件即可。

图片字段只存相对路径，不要存 Base64 字符串。Base64 会把图片体积放大三分之一以上，塞进数据库里直接拖慢查询性能。正确做法是把图片文件存到服务器磁盘或者对象存储，数据库里只保存“/upload/dish/20240512a.jpg”这样的路径。

3. Django 用户端接口落地：购物车与下单的完整链路

3.1 接口划分与 Token 鉴权

用户端接口服务用 Django 实现时，我采用的是标准的 DRF 分层结构。接口按业务模块划分成四组：用户模块负责注册、登录、获取个人信息；菜品模块负责浏览分类、获取菜品列表和详情；购物车模块负责加购、减购、查看和清空购物车；订单模块负责创建订单、查询订单列表和订单详情。

鉴权方案上，用户端没有用 Session，而是用了 Token 认证。原因很简单，用户端的调用方可能是微信小程序、H5 页面，甚至可能是别人写的第三方客户端，Session 依赖 Cookie 的机制在这些场景里并不友好。Token 的方案是：用户登录成功后，服务端生成一个随机 Token 返回给客户端，客户端每次请求在 HTTP Header 里带 Authorization: Token xxx，服务端根据 Token 找到用户。这种方式天然适合跨端调用。

DRF 里面配置非常简单，我习惯在 settings.py 里显式指定默认认证类：

REST_FRAMEWORK = { 'DEFAULT_AUTHENTICATION_CLASSES': [ 'rest_framework.authentication.TokenAuthentication', ], 'DEFAULT_PERMISSION_CLASSES': [ 'rest_framework.permissions.IsAuthenticated', ], }

然后再补充一个 login 接口，在校验用户名密码通过后，用generate_token生成一段随机字符串写入数据库并返回给客户端。这样菜品列表、购物车、下单这些接口只需要在视图里正常写业务逻辑，框架层会自动完成身份识别。

3.2 购物车：数量类型与重复下单的边界

购物车是用户端接口里最琐碎的部分。表面看就是加一减一，实际上要注意几个边界。

加购接口的逻辑是：先查菜品是否存在并且处于上架状态，然后查购物车表里是否已经有这个用户对这个菜品的记录。如果已经有记录，就把数量加一；如果没有，就新建一条购物车记录。我把这个逻辑放在一个事务里，并限制单道菜品的购物车数量上限是 99，防止前端异常时出现数量溢出。

减购接口和变更数量的接口也有细节：如果前端传过来的数量小于等于 0，就直接删掉这条购物车记录；如果真是想改数量，比如从 3 份改成 1 份，后端必须重新从菜品表取一次当前库存来判断是否可售。也就是说，前端传的数量只是一个期望值，是否可行要以服务端实时查询结果为准。

这里最容易踩的坑是“购物车表和菜品表不一致”。因为菜品下架、库存变化这些操作发生在管理台，用户端的购物车里可能还躺着之前加购但现在已经下架的菜。所以每次从购物车生成订单时，都必须重新校验菜品状态和库存，而不是直接信任购物车里的数据。

3.3 订单生成：事务、锁与幂等

下单是整个系统里对数据一致性要求最高的接口。整个流程看起来简单：查询购物车，校验菜品，计算总价，减库存，生成订单主表和明细表，清空购物车，返回订单号。但任何一个环节没有做好并发控制，都会出问题。

我特别强调要使用数据库事务包裹整个下单过程，并在更新库存时使用行级锁。Django 的 ORM 里可以这样实现：

from django.db import transaction with transaction.atomic(): cart_items = CartItem.objects.filter(user=user, delete_flag=0) ... for item in cart_items: dish = Dish.objects.select_for_update().filter(id=item.dish_id, status=1, delete_flag=0).first() if dish is None or dish.stock < item.quantity: raise BizException("菜品库存不足") dish.stock -= item.quantity dish.save() # 生成订单明细

这里的select_for_update()会对菜品这一行数据加锁，直到事务提交才释放。第二个用户同时下单时，会等待第一个事务完成后再读取库存，从而避免超卖。对课程设计或小型订餐系统来说，这个方案足够用，性能损耗也可以接受。

幂等是另一个容易被忽略的点。用户在下单页面不小心双击了提交按钮，前端即使做了禁用，网络抖动也可能导致同一个请求被发送两次。最简单的处理方式是让前端在提交时生成一个request_id，后端订单表里对该字段建唯一索引。第二次请求进来时发现相同request_id已经存在，就直接返回第一次创建的订单号，不再重复扣库存。

还有一个细节：订单明细里保存的菜品名称、价格、图片，必须在下单这一刻从菜品表复制一份进去，而不是通过外键关联实时查询。原因很简单，商家完全可能在用户下单之后修改菜价，如果订单明细一直联表查询，历史订单的金额显示就会跟着变化，这在财务上完全不可接受。

4. SSM 管理后台实现重点：权限控制与统计报表

4.1 拦截器管权限、过滤器管编码：职责别混

管理后台是 Java + SSM 的主场。这里要解决的第一个问题就是登录权限控制。管理后台和用户端不一样，用户端走的是无状态 Token，管理后台用的是传统 Session。管理员登录成功之后，服务端把管理员信息放回 Session，后续带 Session 的请求才能访问受保护的接口。

很多初学者会把登录校验写在 Filter 里，但我的建议是：编码相关工作交给 Filter，业务权限校验交给 SpringMVC 拦截器。拦截器可以拿到 Handler 对象，可以做更细粒度的控制，也能方便地放行登录页和静态资源。而 Filter 的职责是解决中文乱码等问题，两者分工明确，代码才不会乱。

拦截器核心逻辑其实很简单：

public class AdminLoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); AdminUser admin = (AdminUser) session.getAttribute("admin"); if (admin == null) { // 判断是否为 AJAX 请求 String requestType = request.getHeader("X-Requested-With"); if ("XMLHttpRequest".equals(requestType)) { response.setStatus(401); } else { response.sendRedirect(request.getContextPath() + "/admin/login"); } return false; } return true; } }

然后在 SpringMVC 配置类里注册拦截器，并设置拦截路径和管理员登录接口的放行路径。如果项目里还有商家角色，可以在 Session 里额外存一个 role 字段，在拦截器里检查 URL 前缀是否匹配角色权限。这里的原则是：不做太复杂的权限框架，但对于课程设计来说，能说明白“为什么用拦截器、拦截器里做了什么”已经足够。

4.2 动态 SQL 处理多条件菜品查询

管理后台的菜品管理页面几乎必然需要组合查询：按菜品名称模糊搜索、按分类筛选、按价格区间筛选、按上下架状态筛选。麻烦在于这些条件可能是“有选、有不选、可能同时选几个”的组合，如果直接写死 SQL，条件一多就全是空判断和字符串拼接，既难看又容易出 SQL 注入问题。

MyBatis 最大的优势就在这里：用 XML 里的<where>和<if>标签动态拼 SQL，可读性比 Java 代码里拼接字符串好太多。以下是我在这个项目里常用的一段菜品多条件查询：

<select id="selectDishList" resultType="com.example.entity.Dish"> SELECT dish_id, dish_name, category_id, price, stock, image, status FROM tb_dish <where> <if test="dishName != null and dishName != ''"> AND dish_name LIKE CONCAT('%', #{dishName}, '%') </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="minPrice != null"> AND price &gt;= #{minPrice} </if> <if test="maxPrice != null"> AND price &lt;= #{maxPrice} </if> <if test="status != null"> AND status = #{status} </if> </where> ORDER BY create_time DESC </select>

这里有两个经验。第一，模糊查询不要直接写LIKE '%${dishName}%'，那会产生 SQL 注入风险，要用CONCAT('%', #{dishName}, '%')配合预处理参数。第二，如果要对排序字段做动态传入，不要直接拼列名，最好在 Java 层做白名单校验，只允许“price、sales、create_time”等固定值传入。

4.3 营收看板：汇总查询与分页

管理后台还有一部分重要功能是数据统计，这也是 Java 侧相比 Django 侧更顺手的模块。营收统计的核心，是把订单表按日期进行分组汇总，每天的总订单数、总销售额、客单价，全部可以通过一条 SQL 完成。

我选用这样一段 MyBatis 查询：

<select id="selectDailySummary" resultType="map"> SELECT DATE_FORMAT(create_time, '%Y-%m-%d') AS stat_date, COUNT(*) AS order_count, SUM(total_amount) AS total_amount, ROUND(SUM(total_amount) / COUNT(*), 2) AS avg_amount FROM tb_order WHERE order_status IN (1, 2, 3, 4) AND pay_status = 1 AND delete_flag = 0 GROUP BY stat_date ORDER BY stat_date DESC LIMIT #{offset}, #{limit} </select>

统计的时候建议用 pay_status = 1（已支付）和 order_status 非取消状态做条件，避免把取消订单也算进营收。如果订单量大了，还可以给 create_time 建索引提升分组查询效率。报表模块再加上基础的分页展示，一个实用的营收看板就有了。

5. 部署联调与调试文档：让下一个开发者少走弯路

5.1 双服务共存的启动顺序与端口约定

两套后端服务部署起来比单栈项目要多注意启动顺序和端口规划。我整理的启动流程是：先启动 MySQL 服务，导入初始化 SQL 脚本；然后启动 SSM 管理的 Tomcat 服务，默认端口是 8080，SSM 打包成 war 放入 Tomcat 的 webapps 目录；接着启动 Django 服务，默认端口是 8000；最后才是小程序和前端开发环境。

端口规划上给出一个固定约定，避免两个服务互相占用：

两个后端连接同一个数据库实例时，要注意数据库账号权限问题。如果用的是 root 账号，生产环境肯定不合适，但对本地开发调试来说，问题不大。要注意的是 Django 的 settings.py 和 SSM 的 jdbc.properties 里，连接串必须保持一致的字符集与时区配置，否则会出现两边查到的中文乱码、时间差八小时。

5.2 跨域、时区、中文编码三位一体排查

前后端联调阶段，大部分问题集中在这三件事上：跨域被拦截、时区显示错误、中文变成问号或乱码。这三类问题的排查方向完全不同，我列了一个简单的对照表，可以帮你快速定位：

跨域问题在 Django 端用django-cors-headers就能解决，在 SSM 管理后台也可以用 Spring 的 CorsFilter 配置允许来源。如果前端只是纯 HTML 页面直接双击打开，可能会出现两次跨域问题，建议开发时统一走前端开发服务器进行代理转发，能少踩很多坑。

5.3 调试文档中值得写进去的六项内容

“源码 + LW + 调试文档 + 讲解”这套材料里，调试文档往往被当成最不需要花心思的部分，但这其实是个误区。调试文档不是给答辩老师看的装饰，而是给三个月后的自己看的。

我建议调试文档里至少包含六个部分：第一，完整的运行环境清单，包括 JDK 版本、Maven 版本、Python 版本、MySQL 版本、所需 pip 包列表；第二，数据库初始化脚本的位置和导入方式，最好附带两个测试账号，一个用户端账号、一个管理员账号；第三，详细的启动步骤，从数据库到 SSM 再到 Django 的启动顺序；第四，常见报错索引，把部署过程中可能遇到的高频问题列出来并给出对应解法；第五，核心接口清单，用表格列出请求路径、请求方式、参数和返回示例；第六，数据库表和字段的简要说明，配合一张手绘的 ER 图最好。

这份文档的价值在于，当你在答辩现场被问到“这个项目部署时遇到的最大问题是什么”时，你能直接翻出调试文档里的实际记录，这种由真实经历支撑的细节，比任何空泛的套话都有说服力。

6. 实测踩坑记录与产品化优化方向

6.1 并发下单时的重复提交与库存超卖

我在压力测试阶段租了一台普通配置的测试机，模拟两个用户同时抢购同一个菜品。现象非常典型：库存显示还剩 5 份，两个用户同时下单各买 3 份，理论上应该有一个用户买不到，但实际结果是两个用户都下单成功，库存最终变成了 -1。

原因就是经典的“先查后改”竞态。用户 A 查到库存是 5，用户 B 也查到库存是 5，A 扣减到 2，B 也扣减到 2，两次都认为自己操作成功。修复方式就是前面提到的select_for_update()行级锁，让并发请求在数据库层面串行化，A 事务提交之前 B 无法读取同一行数据。

另外还要提醒一个和超时相关的坑：如果用户下单后一直不支付，库存一直被占用，导致其他用户无法购买。解决方案是启一个定时任务，扫描创建时间超过 30 分钟且仍处于待支付状态的订单，自动取消并回补库存。这个逻辑虽然写在代码里只有几十行，但对整个系统的可用性提升非常明显。

6.2 订单明细要快照而不要关联查询

我第一次设计订单表的时候偷懒，订单明细里只存了 dish_id，页面展示订单时再通过菜品表联表查出菜名和价格。后来测试发现，商家在用户下单以后修改了菜品价格，用户在“我的订单”里看到的历史订单金额也跟着变了，这显然不对。

后来我把下单逻辑改成了快照模式：生成订单明细时，把菜品名称、单价、图片路径从菜品表里复制一份写进订单明细表。这样即使商家之后改了价格，历史订单仍然保存着下单那一刻的快照数据。购物车和订单表不一样，购物车是临时数据，菜品价格变了购物车显示新价格没有问题，但订单一旦生成就是不可变的事实记录。

这个设计思路对所有交易类系统都适用。只要是涉及金额、名称等关键信息的业务表，都要考虑快照，而不是依赖实时联表查询。

6.3 从演示项目到一个真实订餐产品的优化清单

课程设计项目往往停留在“能跑起来”的层面，但如果真想把它推向真实应用场景，要补的东西还很多。这里列一份我实际思考过的优化清单，供后续扩展参考。

数据访问层面，可以把热门菜品和首页分类菜单放入 Redis 缓存，降低 MySQL 的查询压力；订单高峰期如果担心数据库写入压力，可以引入消息队列异步处理支付回调后的状态更新。业务功能层面，可以补充优惠券、会员积分、满减活动、菜品口味备注和打包费计算，这些都是订餐产品的常见需求。配送层面，可以引入骑手角色，把订单分配给骑手并增加配送路线的基本抽象。工程化层面，可以补充日志采集、接口耗时统计、全局异常处理，以及更细粒度的权限控制。这套系统本身是一个很好的起点，它的模块划分足够清晰，后续无论是替换某一层技术组件，还是拆分微服务，都有明确的依据。

坦白说，这套系统离一个能直接上线的餐饮产品还有明显距离，但把它从一个纯教学项目变成能演示、能扛住一定并发测试、能在答辩现场讲清楚每个设计取舍的过程，本身就是最大的收获。最后分享一个我在整理项目文档时保留的小习惯：我会在项目根目录放一个 README.md，里面不是标准的框架说明，而是整个调试过程踩过的所有坑和对应的解决方案，旁边标注一句“当时为什么卡住”。这些真实的排查记录比任何优化方案都值钱，因为半年后再打开这个项目，真正能把你从崩溃边缘拉回来的，永远是那些亲历过的问题以及当时找到的原因。