企业官网建设流程全解析

做课程设计最怕的不是不会写代码，而是不知道从哪下手。这次要聊的项目是“基于Java+SSM+Flask的中小型餐厅网站”，技术栈从Java的SSM（Spring+SpringMVC+MyBatis）延伸到Python的Flask，还带着源码、LW文档、调试文档、讲解资源这一整套交付物。如果你正在准备Java方向的课程设计或者毕业设计，这个项目是一个非常典型的参考样本，它不像网上那些纯增删改查的小demo，而是真正把两个主流的Web框架组合在一起干活，既能体现后端功底，又能展示技术广度。

我自己带过不少学生在做这类系统，餐厅网站是出现频率最高的题目之一，原因很简单：业务场景足够生活化，用户、菜品、订单、购物车这些概念谁都能理解；但真要把它做完整，又会牵扯出权限控制、事务处理、前后端交互、部署调试等一系列硬核问题。这篇文章我就以这套系统为例子，把项目骨架、技术选型逻辑、核心功能设计、环境搭建、关键实现、以及我踩过的坑从头到尾捋一遍，给准备做同类项目的同学一份可以直接照抄的实操参考。

1. 项目整体设计：SSM+Flask这套“双引擎”到底怎么分工

1.1 这到底是个什么样的系统

中小型餐厅网站，说白了就是一个餐厅的线上门面加管理系统。顾客进网站能看到菜品列表、分类浏览、菜品详情、用户注册登录、加入购物车、提交订单、发表评论；管理员进后台能管理菜品分类、菜品上下架、处理订单状态、管理用户、查看评论、看基础数据统计。

这套系统最值得琢磨的地方在于它用了两套后端技术：Java的SSM做主体业务，Python的Flask做辅助服务。很多人第一次看到这个组合会困惑，觉得为什么不干脆全用Java，或者干脆全用Python。我最初也这么想，后来把一个真实项目跑通之后才明白，这种“SSM主业务+Flask辅助服务”的组合在课程设计场景里其实非常聪明。

SSM负责的核心是强业务逻辑和事务性操作：用户注册时密码要加密存储，订单提交时库存要扣减、订单明细要同步插入，这些操作必须依靠Spring的事务管理来保证一致性。而Flask在这套系统里承担的是数据辅助类服务，我采用的是最常见的分工方式：Flask独立部署一个端口，对外提供菜品推荐API和访问统计API。

简单说，SSM是那个管账的会计，Flask是那个做分析的助手。会计管的是每一笔业务的准确性和完整性，助手管的是“哪些菜卖得好”“给这个用户推荐点什么”这类偏分析、偏轻量的事务。

1.2 为什么用SSM而不是Spring Boot

这里要特别解释一下选型问题。现在很多新项目都直接用Spring Boot，它把配置简化了一大截，启动也快。但课程设计和毕业设计场景里，SSM依然是评委老师最熟悉的套路，也是最能体现“你懂配置原理”的组合。

我用一个生活化的比喻：Spring Boot是精装修的公寓，拎包入住；SSM是清水房，水电管线都得自己走一遍。你要交房给老师看，精装修当然好看，但如果老师随口问你“SpringMVC的DispatcherServlet在web.xml里怎么配的”“MyBatis的SqlSessionFactory是你自己创建的吗”，住公寓的人大概率答不上来，而自己装过水管的人三言两语就能讲清楚。这就是SSM在答辩环节的隐性优势。

Spring负责对象管理和事务控制，SpringMVC负责HTTP请求的分发和响应，MyBatis负责数据库的持久化操作。三层各司其职，每一层都有大量可讲的设计细节。做这个项目你至少要把web.xml里的Spring容器配置、SpringMVC的前端控制器配置、MyBatis的Mapper扫描和事务通知配置亲手写一遍，这比在Spring Boot里看自动配置要有价值得多。

1.3 Flask在这套系统里的具体职责

我在这套系统里让Flask承担了两个明确的API服务。第一个是菜品推荐接口，针对已登录用户，读取该用户最近的历史订单和浏览记录，做一个基于菜品品类偏好的简单统计推荐；针对未登录用户，直接返回全局热门菜品Top10。第二个是访问统计接口，前端每个页面加载时往这个API发送一个轻量级的事件上报，Flask把访问量和各菜品PV存到独立的SQLite库里，管理员后台定时拉取展示成简单的趋势数据。

这两个功能如果在SSM里自己写，也能做，但会比较笨重。Java写一个推荐逻辑本身没什么难度，但做数据聚合、正则清洗、甚至后面想加个简单的协同过滤算法，Python写起来就轻巧得多。更关键的是，Flask的代码量极短，一个app.py加几个路由函数就完事，整个项目里它扮演的是“小而美”的工具角色，不会喧宾夺主，却能让整个系统的功能维度提升一截，论文里也好写，评语里可以多一条“系统使用Java与Python双语言架构，实现了业务与算法的分离”。

后端接口的联调用的是最普通的HTTP请求，Java端通过Spring的RestTemplate去调用Flask的接口，两边只约定好返回的JSON数据格式，互不侵入，部署的时候两个进程分开启动就可以。

2. 核心功能模块与数据库设计思路

2.1 前台功能模块怎么拆

餐厅网站的前台是给普通顾客用的，功能拆解下来大概是这几个模块。

用户模块负责注册和登录。注册时密码要做MD5加盐处理，绝对不能明文存库，然后把用户基本信息写入用户表，登录时校验密码并往Session里写入用户标识。这块还有一个容易被忽略的点：用户名的唯一性校验要在注册时做好，否则后面做购物车和订单关联时会出现一对多数据错乱。

菜品模块是前台的灵魂，按菜品分类展示，每个分类下用分页控件控制展示数量。菜品列表的每一张卡片上放图、名称、价格、月销量，点击进入详情页后展示更完整的信息，包括菜品介绍、图片大图、评论列表。分类切换时前端可以通过Ajax异步刷新列表，也可以做整页跳转，课程设计阶段用整页跳转更稳，不容易出Bug。

购物车与订单模块是全场复杂度最高的地方。用户可以把菜品加入购物车，购物车列表展示数量、单价、小计，可以修改数量或删除条目。提交订单时要先生成主订单记录，再循环创建订单明细，同时清空该用户的购物车数据。这里必须用数据库事务包住，任何一条插入失败都要整体回滚，我之前见过不少同学在这一步出现“订单生了但明细丢了”或者“购物车没清干净”的问题，基本都是没做事务。

订单支付环节我不建议接真实支付，课程设计里做一个模拟支付就行，点击“去支付”后弹一个确认框，确认后把订单状态从待支付改成已支付。如果要做得更讲究一点，可以额外生成一个订单编号，规则比如“日期+用户ID+随机数”，方便后续做订单号追踪。

2.2 后台管理模块的设计要点

后台是餐厅管理者的操作台，权限和前台要分开。最简单可靠的方式是给用户表加一个role字段，0代表普通用户，1代表管理员。后台的每个Controller方法在进入前先做一次拦截器校验，判断当前登录用户的role值，不是管理员就直接重定向到前台首页。

菜品管理做的事情最多：新增菜品要上传图片、填写名称、价格、分类、描述、库存；编辑菜品要支持图片替换；删除菜品要考虑是否有关联的订单明细和购物车记录，我建议做逻辑删除（加一个status字段置为1）而不是物理删除，否则历史订单的显示会出问题。

订单管理里管理员需要查看所有订单列表，按状态筛选（待支付、已支付、已发货/已完成、已取消），并可修改订单状态。这里我踩过一个坑，如果订单状态是全链路变化的，建议在订单表单独放一个current_status字段，而不是让前端去推导，否则后台筛选会乱。

评论管理相对简单，用户在前台给某个菜品发表评论，后台管理员可以查看所有评论列表并支持删除，防止恶意内容。评论表设计时要把user_id和dish_id都带上，前台展示评论时要连表查出用户名，不然显示一个数字ID非常难看。

2.3 数据库表设计实操

数据库是整个系统的地基，我直接给出我当时设计的一套表结构，字段名和类型都是一线常用的风格，适合MySQL 5.7或8.0。

用户表：字段包括id、username、password（加盐后的密文）、salt（盐值，也可以用固定盐，但每个用户独立盐更规范）、nickname、role、phone、avatar、create_time。需要注意salt字段长度至少要32位，我见过有人设20位，后面换加密算法时发现不够用。

菜品分类表：id、name、sort（排序值）。分类表字段不用太多，名字和排序就够。

菜品表：id、category_id、name、description、price、image、stock、sales、status、create_time。其中price用decimal(10,2)存，千万别用float，浮点精度问题在订单金额计算时会坑你一次。image字段存图片的相对路径，建议统一格式为“/upload/xxx.jpg”，方便页面拼接访问。

购物车表：id、user_id、dish_id、quantity、create_time。联合唯一约束（user_id, dish_id）很重要，同一个用户同一道菜不应该出现多条记录，有约束在就能靠插入时冲突去更新数量。

订单主表：id、order_no、user_id、total_amount、status、create_time、pay_time。status用Int类型存状态码，0待支付、1已支付、2已完成、3已取消，方便筛选和统计。

订单明细表：id、order_id、dish_id、dish_name、price、quantity。注意明细里要把dish_name和price冗余存下来，因为菜品可能被管理员删除或改价，如果明细只存dish_id，历史订单显示时就会对不上。

评论表：id、user_id、dish_id、content、score、create_time。score可以做简单的评分，前台展示时用星标或数字均可。

这套表设计看着朴素，但已经能完美支撑前台浏览、购物车下单、后台管理、统计报表这些核心链路。做课程设计千万别一上来就设计二十多张表，业务没复杂到那个程度，表少了功能完整，表多了反而自找麻烦。

3. 环境搭建和核心配置，从零开始配通SSM和Flask

3.1 基础开发环境准备

工欲善其事必先利其器，先把环境列清楚。我的习惯是：JDK 1.8（或者11，但1.8最稳，网上资料也最多）、Maven 3.6.3、Tomcat 8.5或9、MySQL 5.7、IDEA、Navicat（或者直接用命令行也行）、Python 3.8以上。

这里有一个非常关键的版本匹配问题：JDK版本和Tomcat版本必须兼容，JDK8配合Tomcat8.5是黄金组合，如果你机器上已经是JDK17还想用老Tomcat8.5，启动时会报class版本错误，处理起来很麻烦。

数据库装好后先建一个库，名字我用的是restaurant，字符集选utf8mb4，这个字符集能正确存储emoji表情，如果论文里要提到“支持特殊字符评论”就能用上这一条。导入表的SQL时记得看一下每个字段的排序规则是不是utf8mb4_general_ci，不然中文乱码问题会在后面的查询里冒出来。

3.2 SSM整合核心配置逐段解析

SSM整合首先要有一个标准的Maven工程结构，大致是src/main/java、src/main/resources、src/main/webapp这三块。Maven的pom.xml里要引入Spring核心包、SpringMVC包、MyBatis包、MyBatis-Spring桥接包、MySQL驱动、Druid连接池、Jackson（处理JSON）、JSTL标签库。这里最容易出的问题是版本冲突，Spring和SpringMVC的版本必须一致，哪怕差一个小版本都可能在容器启动时冒出奇怪的NoSuchMethodError。

spring-context.xml里需要做的事包括：开启注解扫描（扫描service和dao）、配置Druid数据源、配置SqlSessionFactoryBean（指定MyBatis的mapper.xml路径和实体类别名包）、配置MapperScannerConfigurer（扫描mapper接口生成代理对象）、配置事务管理器并开启注解事务。这几块配置环环相扣，缺一个MyBatis就注入不进Service层。

spring-mvc.xml里要做这几件事：开启注解驱动（mvc:annotation-driven）、扫描Controller包、配置视图解析器（前缀为/WEB-INF/jsp/，后缀为.jsp）、配置静态资源映射（比如/static开头的请求直接映射到webapp/static目录）、配置文件上传解析器（用于菜品图片上传）。还有一个很容易漏的：配置Jackson的消息转换器，否则Ajax请求返回的JSON在时间日期格式上全是时间戳，前端看着很难受。

web.xml里负责组装整个web应用：配置Spring的ContextLoaderListener，加载spring-context.xml；配置SpringMVC的DispatcherServlet，加载spring-mvc.xml，并设置url-pattern为斜杠；配置字符编码过滤器CharacterEncodingFilter，强制UTF-8，防止中文乱码。

3.3 Flask端配置与联调要点

Flask端代码非常轻，我当时的目录结构是一个restaurant_api文件夹，里面有app.py、requirements.txt、data.db（SQLite自动生成）。requirements.txt里只有三个依赖：flask、flask-cors、requests。

app.py里典型的写法是创建Flask实例，然后通过装饰器定义两个路由。第一个是/recommend，接收参数user_id，没有就查全局销量；有user_id就从订单明细表和浏览记录表做偏好统计，返回一个菜品ID列表和名称、图片URL。第二个是/event，接收POST的JSON数据，把事件类型、菜品ID、用户ID、时间写入SQLite。

联调最核心的一步是解决跨域。SSM后台的前端页面跑在8080端口，Flask跑在8081端口，浏览器里从8080页面发请求到8081端口属于跨域请求，不配置CORS会直接被浏览器拦截。我的做法是加载flask_cors库，并在app.py里调用CORS(app)，一行代码搞定。Java端调用RestTemplate时不需要关心跨域，那是浏览器层面的限制，后端HTTP请求天然不受此约束。

启动顺序也有讲究：先启动MySQL，再启动Tomcat（SSM项目打成的war包），最后启动Flask的app.py。如果Flask没启动，网站其他功能不受影响，只有推荐和统计模块报错，这种设计更符合“辅助服务”的定位——挂了不拖累主系统。

4. 核心业务流程的实现细节和关键代码思路

4.1 用户注册登录和权限控制

用户注册这个流程看起来简单，但有几个隐藏细节：第一，注册时要先校验用户名是否已存在，建议用SELECT COUNT(*) FROM user WHERE username=?去查，不区分大小写，避免“Admin”和“admin”同时存在；第二，密码加盐的推荐做法是UUID生成随机盐，然后MD5（密码+盐）拼在一起存，校验时把用户记录的salt取出来重新算一次对比；第三，注册成功后直接跳转到登录页，别自动登录，免得后面Session初始化顺序出问题。

登录成功后我推荐用Session保存一个user对象或者userId，并在拦截器里做统一校验。拦截器实现HandlerInterceptor接口，在preHandle方法里判断当前请求路径是否以/login、/register、/static开头，如果不是，则检查Session里有没有userId，有就放行，没有就重定向到登录页。这个逻辑能一次性保护所有业务接口，比在每个Controller里写if判断要优雅得多。

4.2 点餐下单的核心事务处理

下单是整个系统最容易出Bug的地方，我把流程完整描述一下。用户从购物车页面点击“提交订单”，后端Controller接到请求后先取出当前用户ID，然后调Service层的createOrder方法。Service方法上必须标注@Transactional，方法内部先遍历购物车列表计算总金额，插入订单主表拿到自增订单ID，再逐条插入订单明细表，最后删除购物车记录并扣减对应菜品库存。

这里扣库存的SQL用UPDATE dish SET stock=stock-? WHERE id=? AND stock>=?更安全，先看受影响行数，如果为0说明库存不足直接抛异常回滚。课程设计里不需要做太高级的乐观锁，但这个细节能在答辩时讲出来，老师会认为你考虑到了并发场景。

订单生成后页面跳转到订单确认页，展示订单号和应付金额，点击模拟支付按钮时再发一个payment请求，Service方法里只做一件事：把订单状态从0改成1，并记录支付时间。这个逻辑必须独立成方法，不要和下单耦合在一起。有些同学为了省事，在提交订单时直接把状态置1，答辩被问“未支付订单怎么处理”时就答不上来。

4.3 图片上传和静态资源路径的配合

菜品图片是餐厅网站的脸面，这个功能做不好很掉价。我采用的是把图片上传到Tomcat部署目录下的upload文件夹，保存相对路径到数据库，页面通过相对路径拼接访问。

核心思路是：在spring-mvc.xml里配置MultipartResolver，maxUploadSize设为10MB，然后Controller接收MultipartFile参数，调用transferTo方法把文件保存到服务器磁盘。需要注意保存的文件名必须重命名，用UUID加原始后缀最省心，比如“uuid.jpg”，这样既避免中文文件名乱码问题，也避免重名覆盖。

部署时有一个大坑：IDEA里Tomcat的运行目录和项目源目录不是同一个地方，直接把文件写到src/main/webapp/upload目录里，项目重启后文件还在，但如果用war包部署到独立Tomcat，目录路径就要写真实磁盘路径，不能写相对路径。我建议用System.getProperty("user.dir")动态获取当前工作目录，拼上“/upload/”来拼装存储路径。

4.4 Flask推荐接口的数据交互细节

Flask端输出的是JSON数组，每条包含dishId、dishName、dishImage、reason四个字段。Java端用一个HttpClientUtil工具类封装get和post请求，推荐模块的Service通过RestTemplate发起调用，拿到JSON后用Fastjson或Jackson反序列化成Map或List，再封装成前台需要的对象列表。

如果Flask服务没启动，Java端调用会抛连接异常，这里必须做异常兜底。我的做法是catch异常后执行一个降级逻辑：直接查菜品表的销量TOP10返回。这个设计非常实用，演示当天如果演示机上没启动Python环境，网站照样有推荐模块的样子，不会当众翻车。

5. 部署调试中的常见问题与排查技巧

5.1 404和500类问题定位

做SSM项目最烦的就是遇到奇怪的404或500。我的经验是先看控制台日志，重点看有没有BeanCreationException、ClassNotFoundException、NoSuchBeanDefinitionException。出现前三类基本是配置问题：包扫描路径错了、版本冲突了、Mapper接口和XML的namespace对不上。

前端页面加载样式全部丢失，先F12看控制台的路径，如果CSS请求返回404，说明静态资源配置mapping有问题。SpringMVC拦截了所有请求，你没有对static目录放行，那浏览器就拿不到CSS和JS文件。检查spring-mvc.xml里的静态资源映射配置是否写对了，这一段配置漏掉几乎每个做SSM的新手都会遇到一次。

5.2 数据库连接和中文乱码

启动时如果报Communications link failure，别急着怀疑代码，先确认MySQL服务是否启动、连接串里的IP端口是否正确、用户名密码是否无误。druid连接池的初始化异常信息会把这些原因都打印出来，耐心看日志就能定位。

中文乱码有三个容易同时出现的点：页面乱码要看JSP的pageEncoding和Content-Type是不是UTF-8；数据库存的乱码要看表字段的字符集，MySQL默认可能是latin1，建库建表时必须指定utf8mb4；Java后端读取参数的乱码要看web.xml里CharacterEncodingFilter的forceEncoding是不是true，只设了encoding但没设forceEncoding，在有些Tomcat版本里参数还是会乱。

5.3 Flask和Java联调的常见问题

Flask服务能启动但Java调不通，先用浏览器或curl直接访问Flask的URL，确认接口本身正常。如果浏览器访问没问题，Java报Connection timed out，大概率是Flask绑定的IP地址问题，启动时用了app.run(host='localhost')，但Java连接时写的是127.0.0.1，这在某些机器上会解析不一致，统一用127.0.0.1就不会有歧义。

如果Java端能拿到JSON但前端页面报错，先看返回的JSON格式和我们预期的结构是否一致。我遇到过Flask返回的字段名里有下划线，Java端取的却是驼峰字段名，导致反序列化后全是null。解决方案是用@JsonProperty注解映射字段名，或者Java端定义VO时字段名和JSON完全对齐。

5.4 排查问题的方法论

我给一个自己常用的排查顺序，从外部到内部层层递进：先用Postman或浏览器直接访问接口，判断前后端谁的问题；再查Tomcat本地日志，定位Controller有没有进去；然后看SQL日志，MyBatis配置里打开log-impl为StdOutImpl，就能在控制台看到实际执行的SQL，排查问题效率翻倍；最后再定位是数据处理问题还是页面渲染问题。这套流程熟练之后，大部分Bug十分钟内都能找到根因。

6. LW文档、调试文档和答辩准备的实操经验

6.1 配套LW文档怎么写得快还能拿高分

这套项目的交付物里有LW，也就是论文文档，很多同学在这上面栽过跟头，写成了纯操作手册被老师批“不像论文”。我建议LW的结构按经典顺序来：第一章绪论写研究背景和意义、国内外现状、主要工作；第二章相关技术介绍写SSM框架、MySQL、Flask、开发工具，要写原理和特性，不要只写“我用到了XX”；第三章系统分析写可行性分析和需求分析；第四章系统设计写总体架构、功能设计、数据库设计；第五章系统实现按模块写界面截图加核心代码片段加逻辑说明；第六章测试写测试用例设计表和测试结果。

写文档最实用的技巧是：先快速把第三章到第五章的初稿写出来，再回头补第一章和第二章。因为需求分析、系统设计的内容都是从实现代码里提炼出来的，先有鸡才有蛋，反着写只会卡壳。每个页面放截图时记得把测试数据、页面效果保持一致，不要截完图又把数据改了，答辩老师对对页面和数据库会发现问题。

所有表结构定义建议用三线表格式，字段名、数据类型、是否为空、字段说明这几列一定要齐全，这是答辩老师看得最仔细的部分。E-R图可以用Visio或ProcessOn画，逻辑要清晰，实体、属性、联系这三要素一个都不能少。

6.2 调试文档记录什么最实用

调试文档的重点不是重复代码里已有的注释，而是记录三类内容：第一类是环境搭建的具体步骤，包括JDK、Maven、MySQL、Tomcat的版本和配置过程，写到别人照着做能跑通的程度；第二类是启动系统的完整操作流程，从启动数据库到部署war包再到启动Flask的每一步都列出来，每条命令和注意点写清楚；第三类是常见错误记录表，把踩过的几个大坑列出来，每条写明报错信息、产生原因和解决办法。

这份文档最大的价值在于老师验证项目时不至于找不到你问，也方便你一个月后回头看自己的系统时不用再花半天时间回忆怎么部署。尤其是Flask端，Python环境的依赖安装命令要写清楚，pip install -r requirements.txt这种话要出现，不然换一台电脑根本装不起来。

6.3 答辩时老师最爱问的问题怎么答

答辩环节我觉得不用紧张，但一定要把自己项目里的设计决策想明白。最常见的问题包括：为什么选择SSM框架而不直接用Spring Boot？为什么引入Flask？数据库表为什么这么设计？事务是怎么管理的？登录权限是怎么控制的？图片上传的底层机制是什么？推荐接口的推荐逻辑是什么？

这些问题我在前面的内容里其实都已经讲到了，关键是要用自己的话把逻辑串起来。比如问你为什么用SSM，你答“因为课程设计要体现对Spring配置原理的理解，SSM需要手动整合三层框架，我对整个请求链路和Bean创建过程更清楚，而Spring Boot帮我自动配置后反而少了这部分锻炼”，这句话和照着课本念是完全不同的效果。

如果老师问到Flask的推荐逻辑，你可以大大方方承认是“基于用户历史点餐记录的品类偏好统计”，原理是统计用户下单中各个菜品品类出现的频次，按频次降序推荐同类菜品。说的过程最好配合代码路径和流程图，老师会觉得这个功能确实是你自己写的，而不是网上随便扒来的。

7. 最后再分享几点做这类项目的个人体会

这套餐厅网站项目做到最后，我的体会只有六个字：别贪，别慌，别懒。功能模块不用往死里加，把点餐、下单、后台管理这条主链路练扎实，比堆十个半吊子功能要强得多。另外，代码一定要自己敲一遍，只有亲手配过SSM的环境、亲眼见过那些千奇百怪的报错，答辩时你才真的有底气。

在做Flask辅助服务的时候，我建议你在README里把启动步骤写成一个make脚本或bat脚本，一键启动Flask服务，演示的时候省事又显专业。图片上传目录记得加一个.gitignore，不然以后提交代码时垃圾桶一样的临时图片全被传上去。

这个项目的后续扩展方向也很多：你可以给订单模块加一个简单的销量统计，用ECharts在前台页面展示月销量折线图；可以给Flask端加一个简单的评论关键词统计，做成词云；还可以把下单流程改成支付宝沙箱支付，那技术含量立刻又上一个台阶。不过这些都是后话，先把主体跑通，把论文写好，答辩的时候从容应对，这才是眼下最重要的事。希望这篇文章能给你搭起一套完整的思路，少走一点我当年绕过的弯路。