Java+SSM+Flask商城系统毕业设计全流程复盘

基于JavaSSMFlask的众惠商城系统从选题到答辩的完整复盘每年到了毕业设计季商城类系统永远是Java方向的首选题。原因很简单业务链路完整、技术栈成熟、功能可展示、答辩有话说。但做出来和做好之间差着十万八千里。最近刚好帮某学生完整过了一遍众惠商城系统这个项目从环境搭建到代码调试再到答辩PPT的逻辑梳理我把整个过程里最有价值的部分沉淀成这篇内容给正在做同类课题的同学一个可以直接参考的路线图。这个项目采用JavaSSMSpring SpringMVC MyBatis作为主后端框架同时引入Python Flask作为辅助服务端形成一套双后端架构的商城系统。为什么这么做很简单很多同学的毕设课题要求里明确规定要体现多种技术栈整合能力或者你需要在答辩时多一个技术亮点。Flask在这里不是多余的它可以承担推荐算法、数据统计、爬虫采集或者消息推送等相对独立的服务。先说结论如果你正在做或者准备做类似的商城系统课题这篇内容能帮你少走很多弯路。我会把这个项目的技术选型逻辑、数据库设计、核心业务实现、部署流程、常见问题排查以及答辩时最容易被问到的几个点全部拆开讲清楚。1. 技术选型分析SSM与Flask双后端是怎么配合的1.1 为什么主框架选择SSM而不是Spring Boot这是个很多同学会在答辩时被老师问住的问题。大多数人在做课程作业或毕设时都会默认选择Spring Boot因为它配置简单、开箱即用。但SSM有它特定的价值场景。SSM指的是Spring、SpringMVC、MyBatis这三个框架的组合它是Spring Boot出现之前Java Web开发的经典标配。选SSM做毕设项目的现实理由是高校的教学大纲普遍还是以SSM为主很多学校的毕设题目明确要求使用SSM框架。另外SSM的配置过程比Spring Boot更繁琐但这恰好是答辩时的加分点——你可以把Bean配置、事务管理、拦截器这些底层机制的细节讲清楚而不像Spring Boot那样什么都自动完成了一问三不知。在众惠商城这个项目里SSM的职责很明确处理前台用户请求、后台管理请求、商品和订单等核心业务逻辑。三层架构严格按照Controller-Service-Mapper的层次划分事务边界控制在Service层保证了业务操作的一致性和可维护性。1.2 Flask在系统中扮演的角色如果说SSM负责正经业务那Flask承担的就是边缘计算和辅助服务。实际项目中我在Flask端做了三个功能第一个是商品推荐服务。SSM主系统只需要在用户访问首页时向Flask发一个HTTP请求带上用户IDFlask根据用户的浏览历史、购买记录通过一个简单的协同过滤算法返回推荐商品ID列表SSM再根据ID列表去数据库查完整商品信息。第二个是数据统计服务。商城的后台管理需要一个销售报表我让Flask从MySQL里读取订单数据用pandas做聚合分析生成图表JSON数据返回给前端。你会发现这部分如果用Java写也能写但代码量要多出好几倍。第三个是敏感词过滤服务。用户发表商品评论时SSM把评论内容异步发送给Flask的接口Flask用Python的正则表达式或jieba分词做敏感词检测返回标记结果。这种架构的好处是各取所长Java擅长事务管理、对象建模和大型业务逻辑Python擅长数据分析、文本处理和快速原型开发。而且两个服务之间通过RESTful API通信互不干扰任何一个挂掉都不会导致整个系统瘫痪。注意如果你的课题没有硬性要求多种框架或者你只有两三个月时间建议不要强行引入Flask。双后端架构意味着你要额外处理跨域请求、接口约定、服务部署、两个项目的联调排错这些都是时间成本。但既然课题定了就把它做出彩。1.3 为什么不用前后端分离架构很多同学纠结要不要上VueSpring Boot的分离开发。坦率地说如果是从零开始且对前端不熟JSP这种传统服务端渲染方案最适合毕设项目。众惠商城没有做前后端分离。原因有两点一是开发效率JSPJSTL Bootstrap的搭配能在很短时间内搭建出形态完整的页面不需要处理跨域、Token认证、前端路由这些额外工程问题二是答辩展示时JSP页面的逻辑更直观老师点开网址就能看到效果视频演示也更稳。而且移动端适配方面我用了Bootstrap的响应式栅格系统调整了navbar的折叠断点主系统在手机浏览器上的显示效果和桌面端相差不大基本达到了一套前端兼容多端展示的要求。2. 系统功能模块拆解前台、后台与Flask扩展服务2.1 前台用户端功能用户端是这个系统对外展示的核心我在设计时按照浏览→检索→购买→支付→评价这条购物主链路展开每个环节做扎实。用户注册与登录手机号码密码注册同时记录邮箱作为找回密码的凭证。密码不在数据库里存明文而是用MD5加盐处理盐值是用户注册时间的毫秒级时间戳。登录成功后用户ID和用户名存入Session并设置了30分钟的有效期。这里我特意加了一层安全设计在登录页面表单中嵌入了一个随机token每次请求时校验防止跨站请求伪造攻击。商品浏览与搜索首页展示轮播图推荐位、新品上架、热销榜单三块内容。分类页按商品类别筛选支持二级分类如手机数码大类下面有手机平板配件三个子类。搜索功能做了模糊匹配关键词命中商品名称或描述文字即可返回结果。分页用的是PageHelper插件每次只查询当前页的数据避免一次性加载全表数据导致页面卡顿。购物车购物车数据以数据库表形式保存而不是Session。这样做的好处是用户换设备后购物车内容不会丢这也是答辩时值得提的一个设计决策。购物车表记录了用户ID、商品ID、数量、加入时间在购物车页面还需要联查商品表获取名称、图片、单价、库存。数量修改和商品删除是走异步交互用Ajax和jQuery操作不需要整页刷新。订单与支付流程下单时系统在订单表插入主记录同时在订单明细表插入每个商品的行记录然后清空对应购物车记录。这里我在同一个数据库事务里完成避免出现订单已创建但明细缺失的数据不一致问题。支付这块实际项目中对接第三方支付网关需要企业资质所以我的做法是模拟支付用户点击去支付后跳转到模拟支付页面选择支付方式模拟支付宝或微信然后点击确认支付。支付操作会调用订单Service的payOrder方法把订单状态从待支付改为已支付同时扣减对应商品的库存。这个逻辑在答辩时一定要能讲清楚因为涉及事务和并发是考官最喜欢追问的地方。用户端还有个人中心模块我的订单列表展示、订单详情、我的收藏、我的积分、我的收货地址增删改查、个人资料修改。2.2 后台管理端功能后台管理端是商城的运营中枢。我用一个独立的登录入口管理员账号和密码存储在单独的管理员表中角色只有一种——超级管理员不做细粒度权限拆分因为毕设场景下不需要过于复杂的RBAC模型但如果你想加分可以扩展一个简单的角色表比如运营和客服两个角色分配不同的菜单权限。后台的主要模块包括仪表盘今日订单数、今日销售额、商品总数、用户总数用数字卡片展示、商品管理商品上下架、编辑价格、修改库存、上传商品图片、分类管理大类和小类的树形管理、订单管理查看所有订单、按状态筛选、发货操作、用户管理查看注册用户列表、启用/禁用账号、评论管理审核评论、删除违规内容。商品图片上传功能是这个系统的一个小亮点。我配置了虚拟路径映射图片文件存储在服务器本地的upload目录然后通过一个SpringMVC的资源配置类把/upload/**路径映射到文件系统的物理路径。这样商品图片不存入数据库数据库里只存图片的相对路径避免了数据库表体积膨胀前端访问时直接通过URL就能显示。Flask端的扩展服务我在后台也有对应入口推荐引擎管理查看推荐结果手动调整推荐权重、数据报表中心读取Flask生成的销售图表图片。2.3 Flask端三个服务的接口约定SSM和Flask之间通信用的是JSON格式。我在SSM侧写了一个HttpClientUtil工具类封装了GET和POST请求方法底层用的是Apache HttpClient依赖。三个服务的接口调用关系如下POST /api/recommend入参userId出参{code: 200, data: [1, 5, 8, 12, 20]}表示推荐商品的ID数组GET /api/sales/statistics入参days最近N天的统计出参{code: 200, data: {dates: [...], amounts: [...], orders: [...]}}POST /api/comment/filter入参{content: 评价文本}出参{code: 200, data: {containsSensitive: true, matchedWords: [关键词列表]}}这三个接口的代码量都不大每个大概二三十行Python代码。Flask设置了一个全局的错误处理函数任何异常都会返回标准JSON结构避免SSM侧解析出错。3. 工程实践中的关键代码实现会话、购物车与订单3.1 数据库表设计九张核心表的关系开始写代码之前先把表结构设计清楚。这个项目的数据库一共9张表用户表、管理员表、商品分类表、商品表、购物车表、订单表、订单明细表、收藏表、评论表。还有一张积分表是可选的我当时为了展示额外功能加了但默认不用。订单表和订单明细表是一对多关系通过订单ID关联。购物车表的逻辑主键是用户ID商品ID这样同一用户对同一商品只产生一条记录。我在dao层写了一个updateByUserAndProduct方法购物车页面点击加入购物车时先查这条记录是否存在存在则数量加一不存在则新建记录。这种先查再写的操作在并发下可能会有问题但毕设场景下够用了。推荐在这部分花时间理清楚ER图因为答辩老师通常会看你的数据库设计文档表之间的外键关系如果混乱第一印象就不好了。我在设计文档里画了实体关系图每个字段都标注了类型、约束和含义说明。3.2 登录会话管理从Cookie到Redis的演进思路SSM默认用Session存储登录状态通过Tomcat的HttpSession实现。在这套架构里我用session.setAttribute(userId, user.getId())实现登录状态缓存同时用SpringMVC的拦截器对所有/user/**路径的请求做登录检查如果session中不存在userId跳转到登录页。这个方案在单机部署下完全没问题。但答辩时你可以提一句演进思路如果系统部署到多台服务器就需要用Redis统一存放Session或者换成JWT这种无状态Token方案。这样一句话就能展示你对分布式场景的理解深度。我在拦截器里还做了用户状态检查被管理员禁用的用户即使已登录访问个人中心时也会被强制退出并提示账号已被禁用请联系管理员。这个细节很多同学的实现里没有但它属于那种看起来小但很显专业的功能。3.3 购物车与订单事务处理的代码结构下单流程是事务密集区。我在OrderService里定义了一个createOrder方法用Transactional注解开启事务。代码逻辑大致是先从Redis类缓存这里我用了一个Spring自带的ConcurrentHashMap模拟轻量缓存或直接查库获取购物车商品列表然后计算总金额每个商品价格乘以数量求和创建订单主记录遍历购物车记录创建订单明细批量删除购物车记录最后返回生成的订单ID。加Transactional不是为了好看而是因为创建订单主记录、插入明细、清空购物车这三个操作里任何一个失败整个下单操作都应该回滚。如果不加事务可能出现订单扣了钱但购物车还留着商品的脏数据。库存扣减的逻辑我做了优化在Mapper的SQL更新语句里带上条件stock #{quantity}如果这次更新影响行数为0说明库存不足直接抛出自定义异常商品库存不足事务回滚。这种写法比先查库存再执行更新安全性高得多因为查和更新之间存在时间窗口并发下可能超卖。3.4 自定义异常与全局异常处理Controller层的错误处理如果不用统一方案每个方法里都写try-catch会让代码非常臃肿。我定义了BusinessException也就是自定义业务异常然后在SpringMVC配置一个全局异常处理器方法上标记ExceptionHandler(BusinessException.class)或者实现HandlerExceptionResolver接口捕获所有未处理的异常统一返回错误页面或JSON错误信息。这个设计方案在你的代码文档里是一个值得强调的亮点。它意味着所有业务校验失败时Service层直接throw new BusinessException(商品库存不足)即可前端Ajax调用就能收到标准格式的错误提示不用定义几十个不同的返回值。4. 部署与调试从开发环境到答辩演示的完整流程4.1 开发环境版本选择先明确环境版本这些细节很多同学会在答辩现场翻车所以一定要提前确认好JDK版本1.8。这个版本稳定且Tomcat 8/9都完美兼容不推荐用JDK 11以上的版本因为某些老依赖包可能没有对应版本。Maven版本3.6。用于管理SSM项目的依赖编译打包。Tomcat8.5或9.0。配置好端口和字符编码UTF-8。MySQL5.7或8.0均可。注意MySQL 8.0的驱动名是com.mysql.cj.jdbc.Driver5.7的是com.mysql.jdbc.Driver。Python3.8。安装Flask、pandas、jieba等依赖用requirements.txt统一管理。开发工具方面Java后端用Eclipse或者IDEAPython用PyCharm。IDEA和PyCharm同属一家人用起来顺手。4.2 SSM项目从IDEA到Tomcat的部署步骤我以IDEA为例把部署路径完整走一遍。第一步导入项目。IDEA直接Open项目文件夹选择Maven项目类型等待依赖下载完成。如果下载慢在settings.xml里配置阿里云镜像这是国内环境必备操作。第二步修改配置文件。重点关注三个applicationContext.xmlSpring的总配置文件配置了包扫描和数据源、spring-mvc.xml配置了注解驱动和视图解析器、db.properties数据库连接参数。数据库连接参数要改成你本机的账号密码和端口。第三步配置Tomcat。点击Run Configurations选Tomcat Server然后选Local在Deployment标签页添加Artifact选择war包或war exploded格式。Application context建议设置为/这样访问地址就是http://localhost:8080。第四步准备数据库。在MySQL客户端执行sql目录下的init.sql创建数据库和表结构然后执行data.sql导入初始数据。初始数据里包含了10个分类、50个商品、1个管理员账号和几个测试用户账号。第五步同时启动Flask服务。在PyCharm里打开flaskapi目录运行app.py控制台出现Running on http://127.0.0.1:5000说明服务正常启动。最后在浏览器里访问http://localhost:8080跳转到商城首页前后端都运行成功部署结束。4.3 代码调试的实用技巧我调试过程中最高频用到的技巧是给MyBatis框架开启SQL日志输出。在log4j或logback配置文件里把mapper包下的日志级别调整为DEBUG然后在控制台就能看到每条SQL语句的完整执行内容定位数据库问题会方便很多。排查SQL相关问题时先把日志中打印的SQL复制出来在Navicat或命令行里手动执行一遍看是否能正常返回结果。这个方法百试百灵能快速确认问题是SQL本身、参数映射还是数据库连接。还有一个经验当你修改了Controller或Service代码热部署经常不生效。不要反复改代码浪费时间直接把Tomcat停止再重启用clean package命令重新打包当前模块这样基本上是稳定生效的。4.4 数据初始化与答辩演示注意事项答辩现场演示不是开发环境它是对外展示系统能力的场景有几个细节值得提前演练拷贝一份干净的数据库快照使用mysqldump导出一份初始化数据答辩前如果数据被改乱了直接用这份备份恢复干净状态保证演示流程的可重复性。准备几个真实感强的演示账号一个普通用户账号购物车里有2件商品、待支付订单1个、已完成订单2个一个管理端账号。这样你演示时不需要现场注册、现场下单直接展示有数据的状态观感好很多。Flaky的地方提前预案比如Flask服务起晚了导致首页推荐位异常要准备好一个降级方案比如Flask接口挂掉时SSM端自动返回热门商品而不是空数据。5. 新手常见的坑环境、依赖与业务逻辑排查实录5.1 Maven依赖下载失败与版本冲突这类问题排在踩坑榜第一位太常遇到了。新手打开IDEA导入项目后经常会看到pom.xml上飘红dependency没有successfully resolved。大多数情况下是国内网络环境导致的下载缓慢或超时。解决办法是在Maven的settings.xml中把中央仓库镜像换成阿里云配置如下mirror idaliyunmaven/id mirrorOfcentral/mirrorOf nameAliyun Maven Mirror/name urlhttps://maven.aliyun.com/repository/public/url /mirror版本冲突的问题也值得留意。比如Spring的核心包版本是4.3.20但某个依赖传递了一个4.3.13版本进来这时IDEA会因为重复的类而报错。解决办法是通过Maven Helper插件在pom图里找到冲突的依赖项用exclusion排除掉低版本的那个传递依赖。5.2 静态资源404和中文乱码启动项目后页面样式全丢、图片不显示是静态资源路径配置的问题。SpringMVC默认会拦截所有请求如果没有在配置文件中放行静态资源它就会把.css、.js、.jpg文件也当成Controller的映射去处理。解决办法是在spring-mvc.xml里加mvc:resources mapping/static/** location/static// mvc:resources mapping/upload/** locationfile:/{绝对路径}/upload//中文乱码问题分三个地方排查代码文件编码统一用UTF-8IDEA右下角可以设置数据库连接URL加上useUnicodetruecharacterEncodingUTF-8JSP页面头部设置pageEncodingUTF-8。这三处都对了乱码基本不会出现。5.3 页面能打开但Ajax接口报500这种问题最让人烦躁因为页面加载正常、数据却不显示。优先打开浏览器的F12开发者工具切到Network标签页刷新页面后找到失败的请求查看响应状态码和返回内容。如果是500去查看Tomcat的catalina.out日志文件搜索Exception关键词定位到具体的Controller类名和代码行号。大多数情况是空指针、数据库表字段名与实体类属性不匹配、或者JSON序列化失败。MyBatis的字段映射问题也是很常见的数据库表列名为goods_name而实体类属性是goodsName如果你没有配置驼峰映射。解决办法是在MyBatis配置文件中开启驼峰转换settings setting namemapUnderscoreToCamelCase valuetrue/ /settings5.4 Flask端服务频繁连不上数据库Flask连接MySQL时要注意编码问题。推荐使用Flask-SQLAlchemy或直接pymysql库。连接字符串中要设置charsetutf8mb4以支持emoji字符避免评论功能中用户输入特殊符号导致报错。其次Flask的调试模式debugTrue时服务重启可能会占用端口导致下一次启动失败。报错信息是Address already in use这时候在命令行用netstat -ano | findstr 5000找到进程PID然后taskkill /F /PID杀掉进程再重新启动。6. 这套系统的优缺点复盘与二次开发方向6.1 从真实使用中总结的优点整套系统如果说有什么做得好的地方我认为技术栈的混搭和代码结构的清晰是我的团队在实际实践中最重要的收获。SSM的熟悉度加上Flask的新鲜感让后端看起来不是只有一种套路。还有一个值得提的是代码层面我保持了高内聚低耦合SSM项目完全通过接口调用Flask服务没有任何一个类直接依赖Python端的内部实现这使得两边的代码可以独立修改。文档方面从数据库建表脚本、部署文档、操作手册到答辩PPT的逻辑大纲我在项目交付时一起整理出来了后来查起来真的方便。6.2 客观存在的不足这套系统如果是生产环境它经不起太大流量的考验。Session存储在应用服务器内存中无法支撑多服务器横向扩展数据库没有做读写分离商品图片走本地磁盘都会在并发较高时成为瓶颈。另外接口的安全校验有些简单除了登录拦截之外没有做接口级别的权限验证。这些缺点我不回避在答辩时你甚至可以主动讲出来然后接一句如果做生产级部署可以引入Redis集群会话共享、Nginx反向代理层、OSS存储图片——这反而是加分项。6.3 有价值的二次开发方向如果时间和精力允许以下几个方向可以有效提升系统的完成度和专业度第一接入真实的支付网关。这个需要你拥有一套开放平台商户资质难度最大但它将系统从demo级拉高到准生产级。第二实现秒杀抢购模块。通过Redis预扣库存、消息队列削峰填谷、接口限流三种手段来应对高并发。这个模块是你与性能优化相关的答辩问题之间的桥梁。第三把Flask的推荐算法升级。现在只是一个简单版本可以换成基于用户行为序列的召回模型效果更明显而且这部分内容是纯加分项。7. 最后的经验之谈写完整个系统我最想提醒后来者的一句话是留给联调和测试的时间要比写代码的时间多留两周。双架构系统最考验人的不是写出来而是串起来。Ssm那边调Flask的接口数据格式对不上、编码不一致、网络超时这些问题在任何一边单独开发时都不会出现只有两边真正联跑时才会暴露。另外答辩时展示代码不要贴完整的Spring配置文件那是最无聊的页面。把PPT重点放在三个地方一是双架构协作图就是你如何用流程图展示SSM和Flask之间如何通信二是核心表结构设计和事务处理逻辑三是你自己实现的优化点或创新点哪怕很小比如购物车的先查再写、库存的条件更新、全局异常处理器。这些细节里的东西才是老师愿意给高分的东西。众惠商城这个题目你用心做一遍学到的不仅是一套系统如何搭建更是完整项目从零到一的工程化思维。这个思维在你后续任何一次开发中都值回票价。