做毕设选了“网上奶茶店系统”这个题目我一开始的想法非常简单一个在线商城嘛用户注册登录、浏览商品、加购物车、下单付款管理员后台管理商品和订单JavaSSM一套下来绰绰有余。结果真动手写起来才发现销售统计、常点搭配推荐、评价文本分析这些辅助功能用Java写起来不仅类多、代码长数据一多还不好维护。后来我在架构里加了一个Flask服务专门承接偏计算、偏分析的模块整个系统瞬间清爽了不少。这套系统最终采用的技术组合是JavaSSMFlaskSSM负责订单、会员、商品、库存这些核心业务链路Flask负责推荐、统计、数据分析这类轻量级辅助模块。如果你也正在做同类毕设或者想了解双后端协作的设计思路这篇文章里的分工逻辑、数据库建模、核心代码思路、双服务联调以及论文和调试文档该怎么准备应该能帮你少走不少弯路。1. 为什么是SSMFlask双后端两套技术栈的分工逻辑很多同学看到“网上奶茶店系统”第一反应是“这不就是个单机商城吗”于是老老实实用一套SSM写到底。能跑但代价很大为了算一个销售额Top10你在Java里查完订单表再自己循环分组求和代码写了一两百行回头一看用pandas几行就出来了。所以我在这套系统里做了一个明确的架构决策——核心业务和辅助计算分家。1.1 SSM扛主业订单、库存、会员这类强事务业务SSM是SpringSpringMVCMyBatis的组合。Spring负责管理对象和事务边界SpringMVC提供Web层的请求路由MyBatis负责把SQL和Java对象映射起来。这三个框架组合在一起最适合做的事情就是“写业务”用户注册、登录、商品管理、购物车、下单、库存扣减、订单状态流转。为什么毕设场景里建议用SSM而不是直接上Spring Boot这是我的真实体会Spring Boot虽然配置少、上手快但很多底层机制被自动配置封装掉了。答辩时评委问你“SpringMVC的DispatcherServlet是怎么工作的”你如果只答“不知道自动配置的”印象分会差不少。SSM需要手动写web.xml、Spring配置、MyBatis映射文件逼着你去理解三层架构和框架原理这个东西在答辩时反而是加分项。编码上要注意一个原则Controller只做接收参数和返回结果Service里面写业务逻辑和事务Mapper只做数据持久化。事务一定要放在Service层用Transactional标识。我在做订单模块时把事务直接放在Controller方法上后来加了一个前置拦截器结果拦截器里的逻辑也被包进了事务排查了半天才明白问题出在哪。1.2 Flask管辅助推荐、统计、评价分析Flask是Python的轻量级Web框架代码量极小一个文件就能起一个服务。它在这个系统里的定位不是“第二套业务系统”而是“业务辅助计算器”。举例来说销售统计从MySQL的订单明细表里按日期、品类、商品做聚合用pandas几行代码搞定。常点搭配推荐统计同一个订单里不同奶茶一起被购买的次数输出Top组合。评价情感分析把用户评论分词、匹配情感词输出好评/中评/差评倾向。这些功能用Java写当然也能实现但代码冗长、迭代慢。Python生态里pandas、jieba等库开箱即用开发效率高一个量级。所以我在架构设计时把这类“读多写少、重计算、不涉及核心事务”的功能全部划给Flask。1.3 两者如何协作接口调用与数据读取的边界划定双后端最怕的就是职责不清最后两套系统都在改订单数据出了问题谁都不认。我在这套系统里定了一个简单粗暴的边界规则模块归属数据操作说明用户、商品、购物车、订单、库存SSM读写核心业务全部走SSM评论内容SSM读写用户产生的主数据SSM管理销售统计、品类分析Flask只读只查订单表和订单明细表常点搭配推荐Flask只读写推荐缓存结果可以单独存一张推荐表评价情感标签Flask只读写分析结果表只写自己的辅助表协作模式我建议采用“数据库共享为主、HTTP接口为辅”的组合。Flask直连同一个MySQL数据库但数据库账号只给SELECT权限加上order_by它不可能误改核心表。需要把推荐结果同步给SSM端展示时就提供一个Flask接口由后端定时拉取或者直接让前端请求Flask服务。为了安全Flask接口加一个内部token校验不是内部请求一律拒绝。2. 奶茶店系统的功能清单与数据库建模要点把功能罗列清楚再动数据库是我做这个项目最大的心得之一。网上奶茶店系统表面上看是个标准商城但奶茶本身的商品模型比普通商品复杂一点建模做不好后面订单和购物车代码全是坑。2.1 用户端和管理端的功能全景先看整体功能矩阵。端功能模块具体功能点用户端账号注册、登录、修改密码、个人中心用户端商品分类浏览、关键词搜索、商品详情、多图展示用户端购物车加入购物车、修改规格/数量、删除、勾选结算用户端下单确认订单、选择收货地址、模拟支付、取消订单用户端订单订单列表、订单详情、订单状态跟踪用户端评价对已完成的订单商品进行评分和文字评价管理端商品管理商品CRUD、上下架、库存调整、分类管理管理端订单管理订单列表、接单制作、配送、完成、查看详情管理端用户管理用户列表、禁用/启用账号管理端评论管理查看评价、隐藏违规评论管理端数据统计销售趋势、品类占比、商品Top榜、订单状态分布支付这块我特意说明一下真实对接微信支付/支付宝需要商户号和签名证书毕设和课堂演示很难拿到也没必要。系统里做一个“模拟支付”入口点击后直接把订单状态从未支付改成已支付并生成一条支付流水记录。论文里可以写“预留真实支付接口对接能力”演示的时候用模拟流程反而更稳定。2.2 奶茶SKU的特殊建模规格不是简单的一个字段普通电商的商品规格一般是“颜色尺码”属性少。奶茶不一样用户点单时要选杯型中杯/大杯、糖度全糖/半糖/三分糖/无糖、温度热/常温/冰、加料珍珠/椰果/布丁/奶盖每个维度可能还有价格差异。如果按传统SKU表把所有组合都列出来一个大杯全糖少冰椰果的组合就要单独生成一行几十个商品就会产生几百行SKU维护起来非常痛苦。我采用的折中方案是product表只存基础商品信息比如奶茶名称、分类、基础价格、描述、图片。规格信息用JSON字符串存在product表的sale_spec字段里比如{cup:[中杯,大杯],sugar:[全糖,半糖,三分糖,无糖],ice:[热,常温,冰]}。加料单独一张product_extra表存加料名称和单价用户选加料时按份数计价。价格计算规则是总价 基础价格 杯型差价如果有 加料价格×数量。购物车和订单项会把用户最终选择的规格文本组合保存起来比如“大杯/半糖/少冰/加珍珠”作为快照冗余进订单。这样商品价格和规格以后改了历史订单依然能还原出当时的商品信息。2.3 订单状态机与快照设计订单是电商系统的核心状态设计得好不好直接影响后台管理的体验。我的系统里订单状态流转如下状态值状态含义触发动作可操作方PENDING待支付用户提交订单创建用户取消进入支付PAID已支付/待制作模拟支付成功管理员接单制作MAKING制作中管理员接单管理员完成制作DELIVERING配送中管理员发货管理员确认送达FINISHED已完成确认送达用户评价CANCELLED已取消待支付时取消系统/用户每个状态变更都只在数据库中做UPDATE更新并且记录status_time字段方便后台按时间线展示。我在订单表里还加了一个status_history字段JSON字符串把每次状态变化的时间和操作人都追加进去答辩时展示订单的时间线会很直观。另外一个必须做的是订单快照。用户在购物车加购时看的是商品当前价格但下单后商品可能改价、改名甚至下架。如果订单详情直接关联商品表历史订单显示就会错乱。正确做法是把商品名称、规格文本、单价、数量、小计金额全部冗余到order_item表下单那一刻就把这些数据固化下来。这个细节我在论文里专门写了一段设计理由评委一眼就能看出你做过真实项目。2.4 核心表结构一览实际项目中我设计了这些核心表表名说明关键字段user用户表id, username, password(加密), phone, avatar, statusadmin管理员表id, username, password, rolecategory分类表id, name, sort, statusproduct商品表id, category_id, name, subtitle, base_price, sale_spec, image, stock, statusproduct_extra加料表id, product_id, name, price, statuscart购物车表id, user_id, statuscart_item购物车明细表id, cart_id, product_id, extra_ids, spec_text, quantity, priceorders订单表id, order_no, user_id, total_amount, status, status_time, address_infoorder_item订单明细表id, order_id, product_id, product_name, spec_text, extra_text, unit_price, quantity, subtotalcomment评价表id, order_id, user_id, product_id, rating, content, create_timerecommend_config推荐配置表id, product_id, recommend_product_ids, update_time3. SSM侧核心业务链路的实操实现与踩坑这一部分我挑几个真正折腾过我的点来写都是可以“抄作业”的实战经验。3.1 下单扣库存Transactional不是万能下单模块是系统里最容易出并发问题的环节。初学者最容易写的代码是// 错误示范 Product product productMapper.selectById(productId); if (product.getStock() quantity) { throw new RuntimeException(库存不足); } productMapper.updateStock(productId, product.getStock() - quantity);这个写法在单用户测试时没有任何问题但一旦两个用户同时抢最后一杯“杨枝甘露”两个线程都读到库存还剩1都判断库存充足然后各自扣减最后数据库里库存变成了负数——这就是典型的超卖问题。正确的做法是使用条件UPDATE让数据库自己判断库存是否足够并且在同一个事务里执行// 正确示范带条件的原子扣减 int rows productMapper.deductStock(productId, quantity); if (rows 0) { throw new RuntimeException(库存不足); }对应Mapper XMLupdate iddeductStock UPDATE product SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity} /update如果UPDATE影响行数为0说明库存不够直接抛出异常让事务回滚。整个过程不需要先查库存再做判断天然避免并发覆盖。事务确保下单和扣库存的原子性Override Transactional(rollbackFor Exception.class) public Long createOrder(OrderCreateParam param) { // 1. 校验购物车项 // 2. 生成订单号和订单项快照 // 3. 扣减库存条件更新 // 4. 清空购物车 // 5. 返回订单号 }一个小坑提醒Transactional默认只对RuntimeException回滚如果业务代码里抛出的是受检异常比如IOException事务不会回滚。所以在rollbackFor里显式指定Exception.class保证任何异常都回滚。3.2 MyBatis多表聚合订单详情resultMap写法订单页面要同时展示订单基本信息和订单商品列表也就是一对多嵌套查询。很多同学习惯先在Service里查订单头再循环查订单明细这样会产生N1查询问题——订单多了以后数据库压力巨大。我的做法是直接在MyBatis里用一条SQL加上嵌套resultMap完成。订单头用Order对象订单明细用ListOrderItem定义如下resultMap idOrderResultMap typecom.tea.entity.Order id propertyid columnorder_id/ result propertyorderNo columnorder_no/ result propertystatus columnstatus/ result propertytotalAmount columntotal_amount/ collection propertyorderItems ofTypecom.tea.entity.OrderItem id propertyid columnitem_id/ result propertyproductName columnproduct_name/ result propertyspecText columnspec_text/ result propertyunitPrice columnunit_price/ result propertyquantity columnquantity/ result propertysubtotal columnsubtotal/ /collection /resultMap select idselectOrderDetail resultMapOrderResultMap SELECT o.id AS order_id, o.order_no, o.status, o.total_amount, oi.id AS item_id, oi.product_name, oi.spec_text, oi.unit_price, oi.quantity, oi.subtotal FROM orders o LEFT JOIN order_item oi ON o.id oi.order_id WHERE o.id #{orderId} /select这里用LEFT JOIN而不是INNER JOIN确保订单没有明细时也能查出订单头。collection标签里的字段都加别名防止重名。这个技巧我强烈建议你掌握答辩时讲“如何避免N1查询”很加分。3.3 登录拦截与购物车的会话取舍SSM端我用拦截器实现登录校验。拦截器只拦截需要登录的接口放行注册、登录、首页、商品列表等公开接口。实现思路是public class LoginInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { Object userId request.getSession().getAttribute(userId); if (userId null) { response.setStatus(401); return false; } UserContext.set(userId); return true; } }UserContext是一个ThreadLocal容器保存当前请求的用户IDService层直接UserContext.get()就能拿到当前是谁在操作。请求结束后记得清理ThreadLocal否则高并发下会串数据。购物车我建议存数据库而不是只放Session。Session方案虽然实现简单但用户换浏览器或换设备购物车就丢了而且联网不好时数据同步很痛苦。存数据库的代价是多几张表但用户在任何设备上登录都能看到同一份购物车这个体验就是实实在在的加分项。购物车设计成两张表cart主表和cart_item明细表用户登录后先查有没有未结算的购物车记录没有就创建。3.4 接口参数校验别放在Controller里写一大堆if很多人写Controller时习惯这样PostMapping(/order) public Result createOrder(RequestBody OrderParam param) { if (param.getProductId() null) { return Result.error(商品不能为空); } if (param.getQuantity() 0) { return Result.error(数量必须大于0); } // 继续一堆判断... }接口少的时候问题不大接口一多代码就脏得没法看。我改用JSR303的Validated注解加校验注解参数校验逻辑全部声明式完成public class OrderParam { NotNull(message 商品不能为空) private Long productId; NotNull Min(value 1, message 数量至少1杯) private Integer quantity; NotBlank(message 规格不能为空) private String specText; }Controller里只需要加Validated RequestBody OrderParam paramSpringMVC就会自动完成校验并抛出MethodArgumentNotValidException再用一个全局异常处理器统一转换错误消息。这样Controller干净了校验规则也集中在实体上维护起来一目了然。4. Flask辅助模块落地把Python的优势用起来Flask在系统里的角色是辅助计算我把三个典型模块的落地思路写出来你可以直接借鉴。4.1 用pandas做销售统计替代Java里十几遍for循环后台管理端的数据看板需要展示近7日销售趋势、各品类销量占比、商品销量Top10等。这个统计逻辑放在SSM里写核心代码是循环嵌套加Map计数放到Flask里用pandas两行搞定。我的实现思路Flask从MySQL里读取订单状态为FINISHED和PAID的订单明细数据然后按日期分组import pandas as pd from flask import Flask, jsonify from sqlalchemy import create_engine app Flask(__name__) engine create_engine(mysqlpymysql://stat_user:readonlylocalhost/tea_shop?charsetutf8mb4) app.route(/stat/sales_trend, methods[GET]) def sales_trend(): sql SELECT DATE(oi.create_time) AS day, SUM(oi.subtotal) AS amount FROM order_item oi JOIN orders o ON oi.order_id o.id WHERE o.status IN (FINISHED, PAID) GROUP BY DATE(oi.create_time) ORDER BY day df pd.read_sql(sql, engine) result { days: df[day].astype(str).tolist(), amounts: df[amount].round(2).tolist() } return jsonify(result)前端用ECharts画折线图时直接请求这个接口拿days和amounts两个数组即可。整个统计模块代码量不到100行而且逻辑清晰接口报错也好排查。4.2 一个简单可用的“常点搭配”推荐逻辑推荐模块我没有上协同过滤、矩阵分解这些复杂的算法因为毕设场景下更重要的是“效果可见、逻辑可解释”。我采用了一个基于商品共现次数的推荐方案从order_item表里找出所有订单ID和对应的商品ID集合。统计同一个订单中任意两个商品一起出现的次数。次数越高的商品对说明搭配购买越频繁。对每个商品取TopN搭配商品写入recommend_config表。商品详情页展示“经常一起下单”时直接读取这张表。Python实现的核心逻辑大概是from collections import Counter order_items pd.read_sql(SELECT order_id, product_id FROM order_item, engine) grouped order_items.groupby(order_id)[product_id].apply(list) pair_counter Counter() for items in grouped: for i in range(len(items)): for j in range(i 1, len(items)): pair_counter[(min(items[i], items[j]), max(items[i], items[j]))] 1统计完成后把每个商品关联的TopN写入推荐表。这个方案简单、性能足够而且答辩时评委问“推荐怎么来的”你回答“基于商品关联共现次数统计”很容易讲清楚。相比上来就写协同过滤然后效果一团糟这种方案显然更有说服力。4.3 评价文本的简单情感识别评价模块除了展示评分我还做了一个情感标签分析把评论内容识别成“好评倾向”“中评倾向”“差评倾向”。这个功能用Python的jieba分词加情感词典就能实现import jieba import jieba.analyse positive_words {好喝, 推荐, 不错, 清爽, 浓郁, 满意, 非常, 喜欢} negative_words {难喝, 太甜, 一般, 失望, 不推荐, 慢, 差} def analyze(text): words jieba.lcut(text) pos_score sum(1 for w in words if w in positive_words) neg_score sum(1 for w in words if w in negative_words) if pos_score neg_score: return positive elif pos_score neg_score: return negative return neutral要注意否定词的干扰比如“不太好喝”里的“不”加“太”实际是偏负面的。我在简单版本里做了个处理如果情感词前一个词是“不”“没”“别”就反转情感极性。这种细节写在论文里会很显诚意。分析完成后结果存到comment_analysis辅助表后台管理端展示评价情感分布图。4.4 Flask在系统里的边界控制Flask辅助模块能正常工作关键在于严格控制它的边界。我给Flask连数据库用的账号是一个只读账号只能SELECT连接串里明确指定了库名。服务器上Flask服务只监听内网地址或本地回环地址不直接对外暴露。如果某个接口需要供SSM前端调用我在接口里加了一个自定义Header校验两边约定同一个token请求没有携带正确token一律返回403。另外还有一点很重要统计和推荐都允许数据延迟。比如新订单刚付款后台看板的数据过几分钟再更新完全没有问题。这样Flask读库时即使加了点计算量也不会拖慢核心下单链路。5. 双服务联调、部署与调试文档的整理思路Java服务和Python服务共存坑主要集中在端口、跨域和环境依赖三块。我一个个说。5.1 端口、跨域与前端代理SSM项目我习惯跑在8080端口Flask服务默认跑5000。前端页面如果是Vue开发服务器跑在5173那就存在跨域问题。开发环境下处理跨域最简单的方式是给Flask服务加一个CORS头。使用flask-cors扩展三行代码搞定from flask import Flask from flask_cors import CORS app Flask(__name__) CORS(app)这里提醒一句生产环境不要靠CORS放开所有域CORS(app)是开发阶段的偷懒方案。生产部署时建议用Nginx做反向代理把/api前缀请求转发给SSM服务把/python-api前缀请求转发给Flask服务。这样对前端来说永远是同一个域名根本不存在跨域问题还能顺带做静态资源缓存和Gzip压缩一举多得。5.2 调试文档到底要写什么调试文档不是把代码注释抄一遍而是写给“从未跑过这个项目的人”看的手册。我整理调试文档时用了这样的结构环境要求JDK 8、Maven 3.6、Python 3.8、MySQL 5.7或8.0、Tomcat 9。初始化步骤创建数据库、导入tea_shop.sql脚本、修改SSM的jdbc.properties、修改Flask的数据库连接串。启动顺序先启动MySQL再启动SSM项目Tomcat最后启动Flask服务。常见问题表。平常最容易翻车的点都集中在这张常见问题表里现象原因解决方法启动SSM时报数据库连接失败MySQL版本和驱动不匹配或连接串缺时区参数确认驱动版本URL加serverTimezoneAsia/Shanghai中文乱码数据库字符集不是utf8mb4建库时指定utf8mb4连接串加characterEncodingutf88080端口被占用其他进程占用了端口换端口或杀进程IDE里改Tomcat端口MyBatis分页不生效PageHelper版本和MyBatis版本不兼容统一升级兼容版本特别注意5.x对应MyBatis 3.4Flask启动后接口报500pymysql或pandas没装pip install pymysql pandas flask flask-cors jieba购物车数据显示不全后端返回的JSON字段名和前端不一致检查实体类字段命名启用驼峰映射mapUnderscoreToCamelCase调试文档的价值在于你写完这个项目后隔一个月再让你自己搭环境也可以照着文档十分钟跑起来。答辩前给导师看一遍老师还能帮你指出环境差异问题比答辩当天才发现部署不上要强太多。5.3 生产环境部署的几个隐藏问题如果把系统部署到Linux服务器有几个坑是Windows本机测不出来的第一MySQL表名大小写问题。Linux上MySQL默认大小写敏感如果代码里写的是Orders而建表用的ordersSQL执行就会报“表不存在”。统一用全小写表名和字段名连接串里设置lower_case_table_names1如果有权限的话可以缓解。第二图片上传路径。商品图片上传到本地绝对路径比如D:/tea_shop/images部署到Linux就没这个目录。建议把上传路径做成配置项存相对路径前面加一个可配置的upload.base-dir部署时改成服务器上的实际目录。Nginx再把这个目录映射成静态资源URL图片访问体验和本机一致。第三Python依赖环境。服务器上不要直接用系统Python跑Flask创建虚拟环境python3 -m venv venv source venv/bin/activate pip install -r requirements.txtFlask服务用nohup或supervisor启动保证SSH断开后服务依然在跑。SSM应用打包成WAR放到Tomcat的webapps目录或者用Spring Boot风格打成JARSSM也可以配置内嵌容器。我习惯用Tomcat因为调试文档里写的启动方式对同学更友好。6. 论文LW和讲解资料怎么用才能让毕设答辩不翻车很多人忙完代码就以为完事了论文和讲解被拖到最后三天硬赶结果答辩时连自己系统的架构图都讲不清楚。这一部分我重点写论文结构和答辩准备。6.1 论文结构怎么对应工程实现标准的毕设论文大致是摘要、绪论、需求分析、系统设计、系统实现、系统测试、总结。要和工程对应到位关键是每一章都要“有图有真相”需求分析阶段画用例图列出用户和管理员的角色以及各自能做的操作。这里我用了两个用例图一个用户端一个管理端比混在一张图里清晰得多。系统设计阶段画总体架构图。我的架构图分三层浏览器端、SSM服务、Flask服务和MySQL数据库中间用箭头标清请求流向。这张图是整篇论文的核心也是答辩时评委盯着看得最久的一张图。数据库设计阶段给ER图把用户、商品、订单、订单明细的关系画出来。论文里重点写清楚订单明细为什么存快照推荐表为什么单独建表这些设计理由比单纯贴DDL有分量。系统实现阶段每个功能模块配一个页面截图加一段核心代码代码量不需要多挑重点比如下单扣库存的条件UPDATE、Flask的统计接口。系统测试阶段列功能测试用例表包含测试项、输入、预期结果、实际结果、是否通过。再加上一个并发扣库存的简单测试说明你考虑过超卖问题这是很好的加分项。论文是工程实现的说理版不是代码的堆砌版。我见过不少同学论文里贴了上百页代码却说不清为什么这么设计答辩时基本一问三不知。建议每写一个模块就问自己一句为什么要这样设计写清楚论文质量自然上去。6.2 答辩演示的流程设计答辩演示最忌讳临时操作、现场翻车。我的建议是准备一套固定的演示脚本按下面这个顺序在答辩前至少演练三遍演示用户端完整点单登录一个演示账号浏览商品选择规格和加料加入购物车提交订单模拟支付。切换到管理端管理员登录从待付款/待制作列表里找到刚下的订单点击接单状态变为制作中再点完成制作、发货最后确认送达状态变为已完成。展示推荐效果重新进到刚才下单的奶茶商品详情页展示页面里的“经常一起下单”推荐商品讲解这个是Flask基于订单共现次数算出来的。展示数据看板打开后台统计页看到销售趋势、品类占比、商品Top榜并说明这些数据来自Flask接口。演示前把数据库恢复到一个干净的演示状态把测试订单和测试数据清掉保证数据和你的讲解节奏完全吻合。另外别用本机演示准备一台独立的演示服务器或者虚拟机避免现场连不上数据库、微信消息弹窗打断、电脑休眠等意外。6.3 高频答辩问题与应答思路根据我自己的经验评委围绕这套系统最爱问的问题基本是这几个问为什么用SSM不用Spring Boot 答SSM手动配置让我更清楚Spring容器、SpringMVC请求流程和MyBatis映射机制有利于理解底层原理。 Spring Boot虽然自动化程度高但作为一个学习项目SSM更能体现三层架构的设计思路。问为什么要在系统里引入Flask 答系统中推荐、统计、情感分析等模块计算密集用Python的pandas、jieba等库可以大幅提升开发效率同时这些模块不涉及核心业务事务拆分到Flask服务不影响订单链路的稳定性。两个服务通过数据库只读账号和内部接口协作边界清晰。问订单状态是怎么流转的如何防止越权操作 答订单表维护状态字段每次状态变更走Service层方法并校验当前状态是否允许跳转状态流转记录追加到状态历史字段。管理端接口通过管理员权限拦截器校验普通用户无法触达。问库存扣减怎么防止超卖 答使用UPDATE product SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}的条件更新结合数据库行锁保证并发安全扣减失败则事务回滚。问统计数据和核心数据的一致性怎么保证 答Flask只读辅助数据统计允许最终一致不需要实时强一致如果要求实时也可以直接查询最新数据但会牺牲部分性能。核心业务数据始终由SSM强事务保证。这些问题你提前准备好答案答辩的时候状态会很从容因为大部分评委考察的就是你是否真的理解了自己做的系统。最后分享一个我做这个项目最深的体会架构不是越复杂越好SSMFlask双后端的关键不在于用了几门技术而在于每一门技术都被放在它最合适的位置上。写代码之前先把数据库设计好把功能边界拆清楚哪怕后面再调整也不会伤筋动骨。希望这篇内容能帮你把网上奶茶店系统做得更扎实预祝你答辩顺利。