做网上奶茶店系统的人不少但大多数项目就是单纯的Java SSM或者单纯的Flask像标题这种“JavaSSMFlask”混搭的组合很多同学第一眼会觉得奇怪——两个后端框架放一起不是给自己找麻烦吗我实际把这套系统的源码、LW文档也就是毕业论文/设计报告、调试文档和讲解视频过了一遍之后反而觉得这种混搭其实很有道理尤其是对课程设计和毕业设计场景来说它既满足了学校要求Java SSM做主体业务的要求又利用了Python生态里做数据分析、推荐算法、图表展示的优势。这篇就围绕这个网上奶茶店系统把它的功能拆解、技术选型、数据库设计、核心代码逻辑、部署调试时踩过的坑以及后续扩展思路一次性讲清楚。1. 网上奶茶店系统的真实业务与功能拆解1.1 从线下奶茶店到线上系统到底要管哪些事奶茶店的核心业务不外乎几件事展示商品、接受下单、制作出杯、完成收款。线下店靠人吼线上系统就得靠一套完整的数据流。网上奶茶店系统说白了就是一个典型的B2C电商系统的缩小版但又有它的特殊性——大多数奶茶是即时制作的所以订单状态里会多出“制作中”“待取餐/配送中”这种环节不像普通电商只有“待发货”。从系统要管理的“事”来看至少包括这么几块商品管理奶茶分类比如经典奶茶、鲜果茶、纯茶、咖啡、单品信息、价格、图片、库存部分原料或杯装库存、上下架状态。用户管理普通用户注册登录、个人信息维护、收货地址、历史订单。购物车临时保存用户想要购买的饮品支持修改数量、清空。订单管理用户下单后生成订单订单里包含饮品明细、总金额、收货方式自取或外卖、订单状态流转。支付功能虽然是课程设计一般不会接真实的支付宝或微信支付但会做一个模拟支付的流程让用户“假装支付”后端再确认支付成功。后台管理管理员登录后可以管理商品、分类、用户、订单可能还有数据统计比如每日销量、销售额排行。如果没有系统这些操作都靠人工记录不仅慢而且容易出错。奶茶店高峰期一单接一单店员既要收钱又要做茶数错金额、漏单是常事。线上系统把“点单-支付-制作-取餐”串起来所有数据留痕还能通过后台看经营状况这就是这个系统的核心价值。1.2 三类角色与六条核心业务流程这套系统里有三类角色分别是普通用户、商家管理员、还有系统本身。整个使用过程可以拆成六条核心流程每条流程基本上都对应数据库中的一张或几张表的操作。用户注册登录用户提交手机号和密码系统校验后存储用户信息后续登录通过Token或Session维持状态。浏览商品用户在首页或分类页查看奶茶列表点击详情查看价格、描述、图片、销量。加入购物车用户选择规格比如大杯、少糖、加珍珠加入购物车可以反复修改。提交订单用户从购物车勾选商品确认收货方式和地址生成订单同时减少库存。模拟支付用户点击“去支付”进入模拟支付页面输入密码或直接确认后端把订单状态从“待支付”变为“已支付/待制作”。商家处理订单管理员登录后台看到新订单点击“开始制作”完成后点击“出杯/配送”用户端可以看到订单状态变化。每条流程都不是孤立存在的比如“提交订单”这一条会同时操作购物车表、订单主表、订单明细表、商品库存表要是没有事务很容易出现订单生成了但库存没扣或者购物车清了但订单明细还在的脏数据。这也是为什么主体要交给Java SSM来做Spring管理事务非常成熟。2. 技术选型为什么JavaSSMFlask混搭反而更好落地2.1 SSM负责主业事务、权限、订单SSM就是Spring SpringMVC MyBatis曾经是国内Java后端开发的主力组合现在很多学校的课程设计、毕业设计仍然指定用它。这套系统把SSM作为核心后端服务负责用户、商品、购物车、订单、支付、后台管理等所有主要业务接口。为什么用它而不是Spring Boot其实底层逻辑一样Spring Boot只是Spring Boot的进一步封装简化了配置。但课程设计用SSM有个“隐藏好处”Spring的XML配置、SpringMVC的控制器、MyBatis的Mapper接口和映射文件都摆在明面上老师一眼能看到你对框架的理解。而且SSM跑在Servlet容器里和JSP、Thymeleaf模板的配合也比较自然很多同学会用JSP做页面也算是一个加分点。Spring在这里最关键的贡献是事务管理。我在调试文档里看到下单接口用了Transactional注解这个很典型。没有事务扣库存和创建订单之间如果出现异常订单记录可能有了但库存没减卖超了都不知道。2.2 Flask负责副业推荐、统计、轻接口Flask是Python领域非常轻量的Web框架它出现在这套系统里并不是为了替代Java而是补Java不擅长的部分。哪些是Java不擅长的比如基于用户行为或者商品标签的推荐算法用Python写起来更直观sklearn、jieba分词库随便调。销售数据的统计分析与可视化比如生成月度销量柱状图、奶茶品类热度饼图Python用pandas处理数据、用echarts渲染图表特别方便。一些轻量的辅助接口比如给用户推荐“可能喜欢的奶茶”或者搜索时做关键词的模糊匹配扩展都可以用Flask快速实现。很多人担心“混搭”会让系统变复杂其实在项目里它们是两个独立的服务有各自的前端页面或者接口。比如用户访问奶茶详情页时页面会同时请求Java后端拿商品数据再请求Flask后端拿“猜你喜欢”的推荐结果两边互不干扰。2.3 两个框架怎么协作共享数据库 HTTP调用两个框架放在一个项目里必须解决协作问题。这套系统的实际做法是共享同一个MySQL数据库通过HTTP接口互相调用。Java SSM管主库负责读写用户表、商品表、订单表Flask进程也连同一个数据库但它只做“只读查询”和“辅助写”比如记录用户浏览行为、算推荐结果。举个具体场景用户下单成功后Java后端生成订单往订单表写数据。Flask后端有一个定时任务或触发接口定期从订单表里读数据统计出本周销量Top10的奶茶然后通过Flask的接口返回给前台页面展示。这里有一个需要注意的地方两个服务如果同时写一张表容易产生锁竞争。因此在设计时要明确“主人原则”比如订单表只有Java服务能写Flask只读。如果有需要Flask写入的数据比如用户浏览日志就单独建一张表互不干扰。我还看到不少同学会在同一台机器上同时启动Java的Tomcat端口和Flask的5000端口这就需要在部署时注意端口配置。后面我会专门讲这个坑。3. 数据库设计与核心表结构3.1 从下单到配送需要哪些表一个网上奶茶店系统标准表设计至少要下面这些表名核心字段作用userid, username, password, phone, avatar, create_time用户信息categoryid, name, sort奶茶分类productid, category_id, name, price, description, image, stock, status商品信息cartid, user_id, product_id, quantity, price, create_time购物车ordersid, order_no, user_id, total_price, status, receiver, address, phone, create_time订单主表order_itemid, order_id, product_id, product_name, price, quantity订单明细bannerid, image, url首页轮播图addressid, user_id, detail, receiver, phone收货地址这些表看着不多但每张表之间的联系要理清楚特别是订单相关的表。订单主表和订单明细表一定是一对多关系一个订单可以有多个奶茶商品。订单主表里的status字段一般用整型或枚举型表示比如0待支付、1已支付待制作、2制作中、3待取餐/配送中、4已完成、5已取消。用数字而不是字符串是为了存储更省空间、查询更快后面写代码的时候再定义一个常量类或者枚举类去对应含义。商品表的stock字段要特别小心。库存扣减不能只靠应用层读出来减一下再写回去否则高并发下会超卖。最稳妥的做法是在SQL里直接更新UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}这样即使两个请求同时来数据库的行锁也会保证只有一个能成功更新。3.2 金额字段的类型选择别被Double坑了我见过太多课程设计里的金额字段用double类型这几乎是必修课级别的坑。Java的double在二进制浮点数运算中会有精度误差比如0.1 0.2你口头算出来是0.3但计算机里可能是0.30000000000000004。奶茶价格虽然简单但订单总价、优惠折扣、积分抵扣都要精确计算一旦出现浮点误差对账就对不上。正确的字段类型是DECIMAL(10,2)在Java实体类里对应BigDecimal。数据库里存的是字符串格式的定点数不会出现二进制误差。MyBatis里查询DECIMAL字段时要把它映射成BigDecimal类型然后所有金额计算都用BigDecimal的方法比如totalPrice price.multiply(new BigDecimal(quantity))别直接用加减乘除运算符。这套系统的调试文档里还特别提了一个点订单创建时前端传过来的价格不能直接信后端一定要根据数据库里的商品单价重新计算订单总金额。这样做是为了防止有人通过抓包篡改价格只花1块钱买一杯30块的杨枝甘露。这也是“后端永远不信任前端”的一个基本原则。3.3 订单状态机与幂等设计的细节订单状态流转看起来简单从待支付到完成其实要考虑很多边界情况。最典型的是“重复提交订单”问题。用户点击下单按钮网络卡了一下他以为没点到又点了一次这时候如果后端没有处理就会生成两笔一模一样的订单。解决办法是给订单生成一个全局唯一的order_no订单编号下单前前端先向后端请求一个预下单接口拿到这个编号再带着编号提交下单。后端检查这个order_no是否已经存在如果存在就直接返回已下单的结果不再重复插入。这个过程叫“幂等”。订单状态的变更也不是随便改的最好做一个状态机约束。比如已经取消的订单不能再变成已完成已完成的订单不能重新支付。虽然课程设计里可能没人恶意操作但写代码时养成为状态流转加校验的习惯后面做项目才能少出bug。4. 核心模块实现登录、购物车、下单、支付模拟4.1 登录模块JWT还是Session课程设计怎么选网上奶茶店系统的用户端和管理员端都需要登录校验。传统课程设计里用Session是很常规的做法用户登录成功后把用户信息放在Session里后续请求通过拦截器检查Session是否存在。用SpringMVC的拦截器实现登录校验代码直观老师一看就明白。JWTJSON Web Token是现在前后端分离项目的主流做法把用户ID、过期时间等信息签名后生成一个token字符串前端每次请求带上后端解析校验。好处是服务端不用存session扩展性好适合前后端分离部署。如果你这个系统是前后端分离的前端用Vue、后端用SSM建议用JWT如果页面是JSP或者模板引擎用Session更简单。这套系统的源码里用的就是JWT主要因为它的Flask辅助服务也需要校验用户身份如果用SessionFlask服务还得共享Session存储比较麻烦。用JWT之后两个服务只要约定好同一个签名密钥和解析逻辑就能互相识别用户身份。4.2 商品SKU与图片上传的路径问题网上奶茶店的商品通常会有“规格”的概念比如大杯、中杯加冰、少冰糖度可选。常规做法是在商品表加一个sku_info字段用JSON字符串存规格选项或者单独建一张sku规格表。课程设计里用JSON字符串是最省事的前端拿到之后自己解析渲染成选择框。但要注意后端在下单时一定要校验前端提交的规格信息是否属于这个商品否则会出现乱加规格的情况。图片上传是另一个高频踩坑点。标题里有一个热词就是“附件路径错误”我推断源码里前期就踩过这个坑。最常见的错误是图片上传成功数据库存了一个路径但页面访问的时候404。原因多数出在路径上面。比如本地上传到了D:/project/upload/但页面访问的URL前缀是/upload/这个URL并没有映射到磁盘目录所以图片加载不出来。解决办法是用SpringMVC配置静态资源映射把/upload/**这个URL映射到本地磁盘路径。在Spring配置里加mvc:resources mapping/upload/** locationfile:D:/project/upload/ /另外还有一个更隐蔽的问题部署到Linux服务器后Windows风格的D:/路径就失效了所以上传路径要写成相对路径或者通过配置文件定义比如upload.path/data/milktea/upload每次从配置中心或配置文件读取。不要写死在任何绝对路径里。Flask服务如果也处理图片上传比如上传用户头像它的static_folder默认是static目录同样要注意路径映射。调试的时候经常出现“Flask能拿到文件但是保存失败”的情况多半是目录权限问题。Linux下要给目录执行chmod -R 755 uploadWindows下要确认文件夹不是只读属性。4.3 购物车合并与下单事务边界购物车功能看起来简单但有几个细节容易漏。一是“同一个用户把同一款奶茶加入购物车两次”是新增两行记录还是把数量累加正常体验应该是数量累加所以加入购物车的逻辑要先查一下购物车表里是否有相同用户相同商品的记录有就更新数量没有就插入。二是购物车和下单的边界。用户下单时事务边界要很清晰扣除库存、生成订单主表、生成订单明细、清空购物车中已经下单的商品。这个事务范围内任何一步失败都要整体回滚。比如库存不够就不能生成订单更不能再清空购物车。我给一个伪代码逻辑参考Transactional public Order createOrder(Integer userId, ListInteger cartIds) { ListCartItem items cartMapper.selectByIds(cartIds); BigDecimal total BigDecimal.ZERO; for (CartItem item : items) { Product product productMapper.selectById(item.getProductId()); if (product.getStock() item.getQuantity()) { throw new RuntimeException(库存不足 product.getName()); } total total.add(product.getPrice().multiply(new BigDecimal(item.getQuantity()))); productMapper.reduceStock(item.getProductId(), item.getQuantity()); } Order order new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(userId); order.setTotalPrice(total); order.setStatus(0); orderMapper.insert(order); for (CartItem item : items) { OrderItem orderItem new OrderItem(); orderItem.setOrderId(order.getId()); orderItem.setProductId(item.getProductId()); orderItem.setQuantity(item.getQuantity()); orderItem.setPrice(productMapper.selectById(item.getProductId()).getPrice()); orderItemMapper.insert(orderItem); } cartMapper.deleteByIds(cartIds); return order; }这里注意在循环里频繁查询商品价格可能会慢正式一点的做法是在循环前把所有商品查成一个Map。课程设计里数据量小问题不大但面试官会看你有没有这个意识。4.4 支付模拟的异步通知机制真实支付系统里用户付款后微信或支付宝会异步回调商家后台接口通知支付结果商家后台确认后修改订单状态。课程设计一般不会真的对接支付网关但可以用“模拟提交流程”近似实现。常见做法是用户点“去支付”进入一个支付页面点击“确认支付”前端调用后端接口/order/pay?orderIdxx后端把订单状态改成“已支付”然后同时调用Flask服务去记录一条支付日志。这样做能演示完整的支付闭环又不涉及复杂的加密验签。不过我还是建议在订单表加一个pay_time字段和pay_type字段记录用户支付的时间和使用的方式余额、支付宝、微信模拟。这样以后要接真实支付只需要增加一个支付回调接口把上面写的orderMapper.updateStatus改成回调里调一次即可业务代码不用大改。5. 本地部署与调试新手最容易撞的5个坑5.1 Windows下Flask Java双服务部署的附件路径错误开头提到的热词“windows flask项目部署到服务器上附件路径错误”这个问题在这套系统里也很典型。很多同学是在Windows本地把项目跑起来的写代码的时候用绝对路径比如app.config[UPLOAD_FOLDER] C:/Users/me/milktea/static/upload上传头像在本地测试没问题但把项目部署到一个Linux服务器上这个路径就会报错因为Linux根本没有C盘。正确的做法是用相对路径基于项目根目录拼接BASE_DIR os.path.abspath(os.path.dirname(__file__)) UPLOAD_FOLDER os.path.join(BASE_DIR, static, upload)不管是Java还是Flask凡是涉及文件路径的一律用动态获取的项目路径 配置文件里的相对路径不要出现任何盘符。另外项目部署的服务器如果和前端不在同一台机器上传的图片URL要使用完整的访问域名或IP端口不能只存一个相对路径否则页面拿到地址后不知道去哪里找图片。5.2 前后端分离的跨域问题这套系统如果前端用了Vue单独起在8080端口Java后端在8081Flask在5000那必然出现跨域。浏览器安全策略默认会拦截跨域请求所以需要在后端配置CORS。Java后端可以用一个Filter统一加响应头response.setHeader(Access-Control-Allow-Origin, http://localhost:8080); response.setHeader(Access-Control-Allow-Methods, GET,POST,PUT,DELETE,OPTIONS); response.setHeader(Access-Control-Allow-Headers, Content-Type, Authorization);如果前端在8080后端在8081Access-Control-Allow-Origin不能设置为*因为设置了*之后浏览器不允许同时携带凭证信息。如果要带Cookie或者Token要么前端每次请求都放在Header里要么就把Origin设为具体的地址。建议统一用Header传Token这样Origin可以放宽一点。Flask这边处理跨域更简单些可以用flask-cors库from flask_cors import CORS CORS(app, resources{r/api/*: {origins: http://localhost:8080}})5.3 端口冲突与数据库连接配置一个项目要启动三个服务Java、Flask、前端端口冲突几乎一定会遇到。最常见的是Tomcat默认8080端口被其他进程占用。排查方法netstat -ano | findstr 8080找到占用进程的PID去任务管理器结束或者换一个端口。我在调试时习惯把这些端口都记下来固定配置到项目的配置文件和前端请求地址里服务默认端口Java SSM后端8081Flask辅助服务5000Vue前端8080MySQL3306数据库连接也容易踩坑特别是MySQL 8.x和旧版驱动之间的认证方式不同。MySQL 8要使用com.mysql.cj.jdbc.DriverURL里还要加useSSLfalseserverTimezoneAsia/Shanghai否则启动时会报时区错误。SSM项目里jdbc.properties配置要仔细核对。5.4 MySQL编码与中文乱码奶茶店系统里商品名、分类、地址全是中文如果数据库表编码不是utf8mb4很容易出现问号。建库的时候就要指定CREATE DATABASE milk_tea DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;Spring连接串也要加jdbc.urljdbc:mysql://localhost:3306/milk_tea?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiFlask连接MySQL如果用SQLAlchemy连接串里同样要加charsetutf8mb4。有个容易被忽视的地方HTML页面的meta标签里如果也声明charsetutf-8那基本不会有问题但如果你用到了JSPJSP页面顶部还要加pageEncodingutf-8控制器返回JSON时也要设置响应编码为UTF-8不然前端拿到的中文就是乱码。5.5 接口联调时最容易出现的空指针和返回格式不一致用户下单时如果查不到商品信息Java里很容易出现NullPointerException这暴露出很多同学写代码时不判空。比如Product product productMapper.selectById(productId); int stock product.getStock();如果product是null第二行直接炸。正确写法是先判断if (product null) { throw new BusinessException(商品不存在或已下架); }在调试文档里我看到这套系统定义了一个统一的Result类格式为{code, message, data}。这是很好的习惯前后端只要约定这个格式解析就统一了。联调时最容易出问题的是“接口返回的结构不一致”比如有的接口直接返回data对象有的接口返回整个Result前端就要写两套判断逻辑。所以建议所有接口都统一走Result包装错误码和错误信息也要有规范表。6. 这套源码能干什么以及再往后怎么扩展6.1 源码目录、LW文档和调试文档怎么配合使用拿到一套课程设计源码第一件事不是急着跑起来而是先看目录结构。这套网上奶茶店系统给的目录大致是milktea-javaJava SSM后端工程milktea-flaskFlask辅助服务milktea-front前端页面可能是Vue或原生HTMLsql初始化数据库脚本LW论文文档逻辑设计调试文档记录了部署步骤和问题解决方案我在实际跑这套项目时建议按这个顺序操作打开sql目录下的初始化脚本先建库建表并插入测试数据。打开milktea-java修改jdbc.properties数据库账号密码启动Spring容器。打开milktea-flask安装依赖pip install flask flask-cors pymysql启动Flask服务。启动前端访问首页注册一个账号正常浏览下单。管理员账号登录后台看订单列表和数据统计。LW文档是给答辩老师看的里面包含系统背景、需求分析、数据库设计、核心代码说明、运行截图等。调试文档则是帮你自己复现验证问题的建议做一步勾一步免得漏掉配置。6.2 从课设到商用可以加哪些功能网上奶茶店系统如果继续往商用方向靠优先级最高的几个功能是积分与会员等级下单送积分积分可以抵扣现金不同等级享受不同折扣。优惠券系统满减券、折扣券、新人券后台可以配置发放规则。门店切换支持多门店用户选择就近门店下单。订单配送追踪模拟外卖骑手的位置更新或者对接第三方配送平台。小程序端奶茶店点单小程序是现在的主流入口后端接口可以复用现有Java接口只需要新做一套前端。消息通知订单状态变化时通过短信、邮件或者小程序订阅消息通知用户。这些功能在现有表结构上扩展不算难。比如积分功能加一张user_points_log表每次订单完成后触发加分优惠券要加coupon和user_coupon两张表再在下单接口里增加校验和抵扣逻辑。6.3 优化思路缓存、索引、图片压缩如果这套系统要扛住真实营业流量优化是必须的。最容易见效的几个点首页商品列表和轮播图加Redis缓存。Redis里存一份商品信息的JSON缓存半小时更新商品时主动清掉相关缓存。访问压力从数据库转到了内存性能提升立竿见影。MySQL的慢查询优化。给orders.user_id、order_item.product_id、cart.user_id加普通索引然后通过EXPLAIN看看查询是否走索引。订单查询时尽量通过订单号查询因为订单号有唯一索引。图片压缩。奶茶商品图片动辄几MB用户打开首页要加载十几张图很容易卡。前端上传时用Java的Thumbnator或者Python的Pillow压缩到宽度800px左右再存到服务器。静态资源放CDN或者独立域名。课程设计用不到但如果部署到云服务器建议把图片放到OSS或者挂载的云存储避免占用带宽。关于Java和Flask的并发能力其实都不适合做极端高并发。Java SSM配合Tomcat单机能扛几百并发Flask默认同步模式更弱一些。如果真要做高并发Flask可以换用gunicorn多worker启动Java这边要改造成Spring Boot 内嵌Tomcat并调优线程池。但课程设计阶段把架构跑通、事务不乱、逻辑严谨已经足够出彩了。我个人在实际调试这套网上奶茶店系统时感受最深的一点是混搭两个框架并没有想象中那么混乱关键是把职责划清楚——Java管钱管订单管事务Flask做推荐做统计做轻量分析前端负责展示。你在答辩的时候如果能把这个设计原因讲明白比单纯背一堆框架名有用得多。最后再分享一个小技巧调试双服务时给Flask配一个单独的日志文件给Java的log4j也单独输出出问题的时候对比两个服务的日志时间线绝大多数问题都能一眼定位。这套系统后续如果往小程序点单方向扩展只需把现有Java接口梳理成标准REST API再套一个uni-app前端就能快速落地。