简介这是一份基于 Spring Boot 与 JSP 技术栈的 Java 网络订餐系统设计源码面向 Java Web 开发者、毕业设计及课程设计人群能够帮助读者快速掌握 Spring Boot 框架与 JSP 动态页面、数据库集成的完整项目开发流程。压缩包共 169 个文件、约 3.1 MB内部资源按用途清晰分类包括 68 个 GIF 界面素材、38 个 Java 核心逻辑文件、23 个 JSP 页面文件、14 个 JPG 图片文件、10 个 XML 配置文件、6 个 JavaScript 交互脚本、4 个 CSS 样式表、2 个 TXT 说明文档以及少量 properties 和 gitignore 文件前端展示与后端逻辑均有良好覆盖。目前已有 287 人学习下载。系统源码覆盖用户注册登录、菜品浏览、在线下单、支付结算、订单管理和用户反馈等主流订餐功能模块同时在设计与实现中考虑了数据加密、SQL 注入防护、XSS 过滤和权限验证等安全因素能够帮助学习者理解真实企业级项目的安全实践。整体上这份源码既可作为 Spring Boot JSP 整合开发的实战教学案例也可作为毕业设计或小型餐饮系统的基础模板便于二次开发和功能扩展。1. 基于SpringBoot和JSP的Java网络订餐系统设计源码到底解决什么问题网络订餐系统是典型的Java Web练习场景但落到工程实现上很多初学者的第一反应是前后端分离SpringBoot做接口、Vue写页面。真正动手后才发现光是一个跨域、一个登录状态同步就能卡住半天。而基于SpringBoot和JSP的Java组合把页面渲染放回服务端Controller取完数据直接丢给JSP不需要CORS配置不需要单独维护API文档一套Tomcat就能跑完整个系统。这个标题背后其实是一套适合毕业设计、课程设计和中小型商户点餐的完整工程骨架用户端菜品列表、购物车、下单、订单状态流转后台的商家接单、菜品管理全都能在一个SpringBoot工程里落地。这套组合有个容易踩的坑SpringBoot默认不把JSP当一等公民内嵌Tomcat缺少JSP编译器打包方式要从jar改成war。如果不清楚这些边界照抄老项目的SpringMVC配置会直接白屏。下文按照工程搭建、业务模块设计、并发处理、上线验证的顺序把这套系统从零到能跑通的最小集合讲清楚。涉及代码的部分都是可以直接复制进IDEA改改就能用的。2. SpringBoot与JSP组合的工程结构设计与视图层配置2.1 为什么JSP还适合留在SpringBoot项目里JSP被很多人当成“过时技术”但在特定场景下它的开发效率比前后端分离高得多。比如订餐系统的商户后台操作模式基本上是“点按钮、刷新页面、看结果”这类表单密集型页面用JSP开发逻辑都在服务端浏览器只负责展示渲染完的HTML排查问题时不用在浏览器DevTools和Network面板之间来回切。用户端的登录态也用Session直接保存JSP里用EL表达式就能拿到当前用户信息不用为了显示一个“您好xx”单独写接口。SpringBoot对模板引擎的默认选择是Thymeleaf但Thymeleaf的表达式方言和标签语法对初学者并不友好处理复杂循环、条件判断时反而没有JSTL的c:forEach、c:if直观。所以“SpringBoot JSP”不是技术倒退而是针对“页面以服务端渲染为主、无独立App复用”场景的务实选择。真正的限制在于SpringBoot对JSP的支持是“能用但不是主流”。spring-boot-starter-web自带的嵌入式Tomcat不包含JSP编译器和JSTL实现必须手动引入tomcat-embed-jasper和jstl。另外SpringBoot默认打可执行jar包时src/main/webapp目录下的JSP文件不会被正确装配到类路径代码里配置了视图解析器也找不到页面所以打包方式必须声明为war。2.2 Maven依赖war包、JSTL与嵌入式Tomcat编译器的选择pom.xml的关键依赖片段如下packagingwar/packaging dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdjavax.servlet/groupId artifactIdjstl/artifactId /dependency dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-jasper/artifactId scopeprovided/scope /dependency /dependencies声明war打包方式是整组配置里最关键的决定。war包可以被外部Tomcat直接解压部署JSP文件保持在/WEB-INF/jsp目录下不会被SpringBoot的打包插件重命名或跳过。tomcat-embed-jasper的provided作用域意思是编译和本地运行时需要它但打包时不需要把JSP编译器塞进war的lib目录因为外部Tomcat自带JSP引擎避免两个编译器冲突。这里还涉及一个SpringBoot版本选择问题。搜索“springboot版本太高”报错的人多半是用3.x版本跑老项目。SpringBoot 3.x把javax.servlet迁移到了jakarta.servletJSP页面里的taglib指令头也要跟着换命名空间网上大量老教程里的% taglib prefixc urihttp://java.sun.com/jsp/jstl/core %在3.x下会编译失败。如果是新写项目优先用2.7.x版本生态兼容性最稳。2.3 视图前缀、编码和文件上传的关键参数配置JSP项目排错半天找不到页面九成是spring.mvc.view.prefix和suffix没配对。视图解析器的作用是把Controller返回的字符串视图名拼接成真实的JSP文件路径。比如Controller返回user/info解析器会去/WEB-INF/jsp/user/info.jsp找文件。注意/WEB-INF/目录下浏览器无法直接访问只能通过服务端跳转进入这本身就是一层不错的页面访问控制。下面是完整的配置server.port8080 spring.application.nameorder-online spring.mvc.view.prefix/WEB-INF/jsp/ spring.mvc.view.suffix.jsp spring.mvc.view.content-typetext/html;charsetUTF-8 server.servlet.encoding.charsetUTF-8 server.servlet.encoding.forcetrue spring.servlet.multipart.max-file-size5MB spring.servlet.multipart.max-request-size10MB spring.datasource.urljdbc:mysql://localhost:3306/order_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai spring.datasource.usernameroot spring.datasource.passwordroot server.servlet.session.timeout30m把关键参数的作用整理成一张表方便配置时逐个对照配置项作用建议取值spring.mvc.view.prefixController返回的逻辑视图名前缀/WEB-INF/jsp/spring.mvc.view.content-type页面响应类型和字符集text/html;charsetUTF-8server.servlet.encoding.force强制请求和响应都使用指定编码truespring.servlet.multipart.max-file-size单个上传文件大小上限菜品图片常用5MBserver.servlet.session.timeoutSession空转超时时间支付流程要留足30mJSP里最容易翻车的中文乱码就是这三层不一致造成的JSP页面顶部的contentType、Spring MVC的响应编码、MySQL连接URL里的characterEncoding。任何一个地方漏掉UTF-8订单地址或菜品名就会变成问号。上面配置里server.servlet.encoding.forcetrue比较关键它保证请求体和响应体都被强制转成UTF-8不会出现只改了页面没改容器的情况。2.4 从Controller到JSP制作一个“个人信息展示页面”订餐系统里用户点击“个人中心”要同时展示用户基本信息和最近订单。这个页面用JSP做非常简单Controller查询数据放进ModelJSP用EL表达式和JSTL标签渲染。Controller的代码Controller RequestMapping(/user) public class UserController { private final UserService userService; private final OrderService orderService; public UserController(UserService userService, OrderService orderService) { this.userService userService; this.orderService orderService; } GetMapping(/info) public String info(HttpSession session, Model model) { Long userId (Long) session.getAttribute(userId); UserVO user userService.findUserById(userId); ListOrderVO recentOrders orderService.findRecentOrders(userId, 5); model.addAttribute(user, user); model.addAttribute(orders, recentOrders); return user/info; } }对应的WEB-INF/jsp/user/info.jsp文件内容% page contentTypetext/html;charsetUTF-8 languagejava % % taglib prefixc urihttp://java.sun.com/jsp/jstl/core % html body h3${user.nickname}/h3 p手机号${user.phone}/p h4最近订单/h4 ul c:forEach items${orders} varo li订单号${o.orderNo}金额${o.totalAmount}/li /c:forEach /ul /body /html这个流程里有一个细节值得注意Controller方法返回字符串user/infoSpring MVC会把它交给视图解析器处理不是直接当响应内容输出。Model里的数据会暴露给视图页面里用${user.nickname}取的是user对象的nickname属性本质是反射调用getter方法所以VO类必须有对应的getter。c:forEach是JSTL的核心标签items对应传入的List集合var声明循环变量比在JSP里写% for(...) %代码块干净得多也更容易维护。到这里SpringBoot和JSP之间的“桥”已经打通。这套配置同样适用于商品列表、订单详情的渲染后面设计核心业务模块时页面展示部分直接复用这套模式即可。3. 订餐系统核心业务模块菜单、购物车与订单状态的设计3.1 数据模型设计哪些表必须拆哪些字段必须冗余订餐系统的表结构按照“主数据”和“交易数据”两个维度来划分最清晰。主数据是用户、商家、分类、菜品交易数据是购物车、订单、订单明细、评价。最小值集如下表名核心字段作用memberid, nickname, phone, password_hash用户登录信息merchantid, name, address, business_hours商家资料categoryid, merchant_id, name菜单分组比如“热菜”“凉菜”dishid, merchant_id, category_id, name, price, stock, pic菜品和库存cartid, member_id, dish_id, quantity购物车ordersid, order_no, member_id, merchant_id, total_amount, status, pay_status, created_at订单主表order_itemid, order_id, dish_id, dish_name, dish_pic, price, quantity订单明细快照订单设计里有一条值得多花点存储换稳定性的经验明细表里冗余商家和菜品信息。比如order_item里单独存一份dish_name和dish_pic将来商家修改菜品名称、价格甚至下架菜品历史订单展示完全不受影响。如果不做这个快照订单列表每次都要关联菜品表取名称菜品一旦删除用户看到的订单页面就会是一排null。用户表的密码字段必须存哈希值推荐用BCrypt加密。很多参考项目直接在数据库里明文存密码答辩或面试时被问“密码怎么存的”会非常被动。数据库连接的工具类、测试类里也不要出现真实账号密码改成读取环境变量。3.2 下单接口为什么事务必须包住扣库存在JSP项目里用户提交订单就是一个表单POST请求。但Controller背后的OrderService.submitOrder要在一个事务里完成三件事检查并锁定菜品库存、生成订单和订单明细、清空购物车。任何一个步骤失败事务回滚数据库停留在操作前状态。核心代码如下Override Transactional(rollbackFor Exception.class) public OrderVO submitOrder(Long memberId, Long merchantId, ListCartDTO carts) { long totalAmount 0L; for (CartDTO cart : carts) { // SELECT ... FOR UPDATE锁住菜品行防止并发下单造成超卖 Dish dish dishMapper.selectByIdForUpdate(cart.getDishId()); if (dish.getStock() cart.getQuantity()) { throw new BizException(菜品库存不足 dish.getName()); } totalAmount dish.getPrice() * cart.getQuantity(); } OrderEntity order new OrderEntity(); order.setOrderNo(generateOrderNo()); order.setMemberId(memberId); order.setMerchantId(merchantId); order.setTotalAmount(totalAmount); order.setStatus(OrderStatus.WAIT_PAY.getCode()); order.setPayStatus(PayStatus.UNPAID.getCode()); orderMapper.insert(order); for (CartDTO cart : carts) { dishMapper.decreaseStock(cart.getDishId(), cart.getQuantity()); orderItemMapper.insert(fromCart(cart, order.getId())); } return OrderVO.fromEntity(order); }这段代码有两个层面保证库存正确。第一层selectByIdForUpdate对应的SQL是SELECT * FROM dish WHERE id ? FOR UPDATE在事务内锁定该菜品行其他事务要更新这一行必须等当前事务提交这是悲观锁。第二层兜底扣减库存的SQL必须写成UPDATE dish SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}即使程序逻辑出了漏洞数据库的条件判断也会拦住超卖。Transactional(rollbackFor Exception.class)里的rollbackFor值得展开讲Spring默认只在抛出运行时异常时回滚如果业务异常继承了Exception而这里没写rollbackFor事务不会回滚订单照样入库库存却扣了。所谓java基本功问到这里基本能区分一个人是“会写SpringBoot”还是“理解SpringBoot”。3.3 订单状态机用枚举收敛状态流转订单状态是订餐系统里最容易被写乱的部分。新手常见写法是直接UpdateWrapper里set(status, 4)多条更新路径互相交叉两周后谁也说不清“已支付”到底能不能跳到“配送中”。正确做法是先画一张状态迁移表再在代码里用状态机限制流转方向。当前状态可迁移状态0 待支付1 已支付0 待支付-1 已取消1 已支付2 商家接单1 已支付5 退款2 商家接单3 配送中3 配送中4 已完成状态机的统一收口放在一个Service方法里比如orderStatusService.transit(orderId, targetStatus)进入方法第一步校验当前状态和目标状态是否存在合法迁移路径不合法直接抛异常。这样所有调用方只能通过这一个入口改状态不会出现绕过校验的强制UPDATE。还需要把“订单状态”和“支付状态”分开存字段。有的流程是货到付款订单已完成但支付状态仍然是“未支付”两个状态混在一起存成4、5、6、7这种魔法数字列表查询会写得极其痛苦。面试题里“如何设计订单状态”的隐含考点就是看能不能把“业务流程状态”和“资金流转状态”解耦。3.4 JSP里的JSON交互购物车页面怎样局部刷新很多搜索“jsp jsonarray import”的人是想在JSP页面里解析后端返回的JSON数组字符串。购物车数量加减就是一个典型场景用户点击加号页面不能整页刷新要用AJAX把菜品ID和数量发给ControllerController返回最新的JSON页面端局部更新。Controller层的接口返回JSON数据而不是视图名GetMapping(/cart/list) ResponseBody public ListCartVO listCart(Long memberId) { return cartService.findCartByMember(memberId); }带ResponseBody注解的方法返回值会由Jackson序列化成JSON字符串Spring MVC不再走视图解析器。这解决了“JSP项目里也能单独提供JSON接口”的需求。JSP页面侧的处理方式% page pageEncodingUTF-8 % div idcartList/div script fetch(/cart/list?memberId%session.getAttribute(userId)%) .then(res res.json()) .then(data { const list data.map(item trtd${item.dishName}/tdtd${item.quantity}/tdtd${item.price}/td/tr ).join(); document.getElementById(cartList).innerHTML table${list}/table; }); /script注意页面里用%session.getAttribute(userId)%直接取服务端Session值拼进URL这是JSP项目的一个优势前后端分离项目里前端要拿到当前用户ID必须调一个接口JSP里Session天然可用。fetch是现代浏览器的原生API返回的res.json()已经完成JSON解析不需要再额外JSON.parse也不需要引入jQuery就能完成局部刷新。4. 并发订餐下的数据库事务与常见部署排错4.1 锁策略悲观锁锁库存乐观锁改资料网络订餐的并发压力不在于整体QPS而集中在少数热点菜品上。比如某个限时折扣菜只剩最后一份两个用户同时点击下单代码如果按“查库存 → 生成订单 → 减库存”三步走两条线程都能查到stock1最后订单生成两份库存变成负数。解决这个问题的核心是在数据库层对库存行加锁。上一章代码里已经用到了悲观锁SELECT ... FOR UPDATE。它在事务内锁住dish表的指定行第二个事务对同一行的查询和更新会阻塞必须等第一个事务提交。这个锁的特点是安全、实现简单代价是并发时会排队。库存这种“竞争激烈、必须立刻拦截”的数据适合用它来兜底。乐观锁适用于“冲突概率低”的更新场景比如用户修改个人资料。实现方式是在表上增加一个version字段更新时把版本号作为条件UPDATE member SET nickname #{nickname}, version version 1 WHERE id #{id} AND version #{version}如果返回的影响行数为0说明更新前版本已被其他事务改过业务层选择提示“信息已变更请刷新重试”。乐观锁没有数据库锁等待在冲突少时吞吐更高但不能无脑用于库存扣减因为购物车场景的并发冲突恰恰集中在少部分热门菜品上冲突率高时乐观锁的重试反而放大数据库压力。4.2 连接池和事务边界一单别拖死整个库SpringBoot 2.x默认使用HikariCP连接池它的默认配置足够应对练习环境但生产环境需要显式控制几个参数。下面是适合订餐系统低并发起步的一组配置spring.datasource.hikari.minimum-idle5 spring.datasource.hikari.maximum-pool-size20 spring.datasource.hikari.connection-timeout30000 spring.datasource.hikari.max-lifetime1800000maximum-pool-size不是越大越好。MySQL默认最大连接数是151一个SpringBoot实例配20两台实例同时部署也才占掉40个连接要给其他后台工具留出余量。max-lifetime要小于MySQL的wait_timeout否则空闲连接被数据库主动断开后连接池还在继续使用日志里会出现Communications link failure。事务边界同样影响连接池。下单方法里只做数据库操作锁库存、插订单、插明细、减库存。短信通知、消息推送这类外部I/O操作要放在事务提交之后执行。如果把这些动作写进Transactional方法内事务会一直持有数据库连接等待外部服务响应高峰期一个慢速短信通道就能耗尽整个连接池。事务里不做远程调用这个原则写进java八股文也不为过。4.3 jsp编译class文件保存在哪里与启动报错排查JSP和普通HTML最大的不同在于JSP第一次被访问时会被容器翻译成Servlet Java源文件再编译成class。这也解释了为什么修改JSP文件后有时刷新页面看不到变化Tomcat的编译产物缓存没有失效。嵌入式Tomcat运行SpringBoot时编译产物在CATALINA_BASE/work目录下外部Tomcat部署时路径一般是TOMCAT_HOME/work/Catalina/localhost/项目名/org/apache/jsp。class文件就保存在这里的org/apache/jsp目录中排查“JSP改动不生效”时先清空这个work目录再重启。“Whitelabel Error Page”是SpringBoot默认错误页看到它说明请求已经到了SpringMVC但视图解析失败九成是spring.mvc.view.prefix配置的路径与实际JSP文件位置不一致。先确认Controller返回的视图名和WEB-INF/jsp/下文件路径是否完全对应再去查路由问题。JSP页面中文乱码则要从三层排查页面顶部contentType是否声明UTF-8Spring的CharacterEncodingFilter是否被禁用MySQL连接URL里是否带的characterEncodingutf8。还有一个容易被新版本SpringBoot坑到的点3.x版本里tomcat-embed-jasper的Servlet API命名空间换成了jakarta.*旧的JSP标签库如果还引java.sun.com/jsp/jstl/core会编译失败。项目升级前建议先在本地起一个环境验证JSP和JSTL兼容性再动代码。4.4 JSP页面离开提示与基础安全收口订餐后台的商家经常在编辑菜品信息时误关标签页。JSP页面里可以注册beforeunload事件在表单未保存时弹出离开确认但直接给所有页面都挂beforeunload会非常烦人因为每次刷新都会弹窗。改进做法是用一个“脏标记”变量控制script let dirty false; document.getElementById(dishForm).addEventListener(input, () { dirty true; }); window.addEventListener(beforeunload, (e) { if (dirty) { e.preventDefault(); e.returnValue ; } }); /script用户输入过内容后才把dirty置为true没有修改直接关闭页面不会打断操作。e.preventDefault()和e.returnValue 两者配合保证Chrome和Firefox都弹确认框。安全这块JSP项目因为是服务端渲染XSS防护容易疏忽。用户昵称、菜品名这类数据不需要展示富文本直接用JSTLc:out输出它会默认转义HTML。SQL注入统一用MyBatis的#{}预编译占位符禁止用${}拼接字符串。下单接口的入参校验检查“菜品是否属于该商家”防止用户传一个merchantId就替别的商家下单这个细节经常作为java面试题出现在项目询问环节。5. 订餐系统上线前的验证、压测与配置收口5.1 用curl模拟一次完整点餐流程服务端本地启动后用curl走一遍“登录 → 加购 → 下单”确认接口链路通顺。注意登录接口通常设置了会话Cookie后续命令要用同一个Cookie文件保持登录态curl -c cookies.txt -X POST http://127.0.0.1:8080/login \ -d phone13800000000password123456 curl -b cookies.txt -X POST http://127.0.0.1:8080/cart/add \ -d dishId3quantity1 curl -b cookies.txt -X POST http://127.0.0.1:8080/order/submit \ -d merchantId1-c表示把服务端返回的Cookie写入文件-b表示发送请求时从文件读取Cookie。下单接口返回200后直接查orders和order_item两张表确认数据落库订单状态应为“待支付”的0这个验证比看页面反馈更可靠。5.2 用wrk压一下菜品列表接口别只看吞吐量上线前用wrk对只读的菜品列表接口做一分钟压测能快速发现连接池、线程池的明显瓶颈。压测POST类下单接口前要确认CSRF和登录校验已经关闭或做了白名单wrk -t4 -c50 -d30s http://127.0.0.1:8080/dish/list?merchantId1-t4开四个线程、-c50保持50个并发连接、-d30s持续30秒。输出结果里关注的不是Requests/sec有多高而是Latency分位数P99超过500ms就说明有线程阻塞或SQL慢查询。同时观察数据库的连接数监控如果连接数被打满优先排查是否有事务没提交。5.3 上线前检查清单照着做一遍最后按这张表逐项收口比反复浏览页面更有效检查项操作方式JSP热部署关闭生产环境关闭spring.devtools.restart.enabled避免JSP修改触发频繁重启慢SQL日志打开MySQL的slow_query_log设long_query_time1数据库账号应用连接账号单独创建只授权业务库不直接使用root配置文件敏感信息application.properties中不放密码用环境变量或配置中心注入最后一道工序是给菜品的主要页面做一次“预热”。JSP的首次访问会触发编译耗时可能达到几秒用户点击首页时恰好踩中这次编译体感就是“系统很卡”。用wget或curl把菜品列表、搜索结果、订单详情这几个高频入口在发布后立即请求一遍让JSP完成预编译真实用户访问时直接从编译产物渲染。这套订餐系统的上线准备到这一步才算真正完毕。本文还有配套的精品资源点击获取
简介这是一份基于 Spring Boot 与 JSP 技术栈的 Java 网络订餐系统设计源码面向 Java Web 开发者、毕业设计及课程设计人群能够帮助读者快速掌握 Spring Boot 框架与 JSP 动态页面、数据库集成的完整项目开发流程。压缩包共 169 个文件、约 3.1 MB内部资源按用途清晰分类包括 68 个 GIF 界面素材、38 个 Java 核心逻辑文件、23 个 JSP 页面文件、14 个 JPG 图片文件、10 个 XML 配置文件、6 个 JavaScript 交互脚本、4 个 CSS 样式表、2 个 TXT 说明文档以及少量 properties 和 gitignore 文件前端展示与后端逻辑均有良好覆盖。目前已有 287 人学习下载。系统源码覆盖用户注册登录、菜品浏览、在线下单、支付结算、订单管理和用户反馈等主流订餐功能模块同时在设计与实现中考虑了数据加密、SQL 注入防护、XSS 过滤和权限验证等安全因素能够帮助学习者理解真实企业级项目的安全实践。整体上这份源码既可作为 Spring Boot JSP 整合开发的实战教学案例也可作为毕业设计或小型餐饮系统的基础模板便于二次开发和功能扩展。1. 基于SpringBoot和JSP的Java网络订餐系统设计源码到底解决什么问题网络订餐系统是典型的Java Web练习场景但落到工程实现上很多初学者的第一反应是前后端分离SpringBoot做接口、Vue写页面。真正动手后才发现光是一个跨域、一个登录状态同步就能卡住半天。而基于SpringBoot和JSP的Java组合把页面渲染放回服务端Controller取完数据直接丢给JSP不需要CORS配置不需要单独维护API文档一套Tomcat就能跑完整个系统。这个标题背后其实是一套适合毕业设计、课程设计和中小型商户点餐的完整工程骨架用户端菜品列表、购物车、下单、订单状态流转后台的商家接单、菜品管理全都能在一个SpringBoot工程里落地。这套组合有个容易踩的坑SpringBoot默认不把JSP当一等公民内嵌Tomcat缺少JSP编译器打包方式要从jar改成war。如果不清楚这些边界照抄老项目的SpringMVC配置会直接白屏。下文按照工程搭建、业务模块设计、并发处理、上线验证的顺序把这套系统从零到能跑通的最小集合讲清楚。涉及代码的部分都是可以直接复制进IDEA改改就能用的。2. SpringBoot与JSP组合的工程结构设计与视图层配置2.1 为什么JSP还适合留在SpringBoot项目里JSP被很多人当成“过时技术”但在特定场景下它的开发效率比前后端分离高得多。比如订餐系统的商户后台操作模式基本上是“点按钮、刷新页面、看结果”这类表单密集型页面用JSP开发逻辑都在服务端浏览器只负责展示渲染完的HTML排查问题时不用在浏览器DevTools和Network面板之间来回切。用户端的登录态也用Session直接保存JSP里用EL表达式就能拿到当前用户信息不用为了显示一个“您好xx”单独写接口。SpringBoot对模板引擎的默认选择是Thymeleaf但Thymeleaf的表达式方言和标签语法对初学者并不友好处理复杂循环、条件判断时反而没有JSTL的c:forEach、c:if直观。所以“SpringBoot JSP”不是技术倒退而是针对“页面以服务端渲染为主、无独立App复用”场景的务实选择。真正的限制在于SpringBoot对JSP的支持是“能用但不是主流”。spring-boot-starter-web自带的嵌入式Tomcat不包含JSP编译器和JSTL实现必须手动引入tomcat-embed-jasper和jstl。另外SpringBoot默认打可执行jar包时src/main/webapp目录下的JSP文件不会被正确装配到类路径代码里配置了视图解析器也找不到页面所以打包方式必须声明为war。2.2 Maven依赖war包、JSTL与嵌入式Tomcat编译器的选择pom.xml的关键依赖片段如下packagingwar/packaging dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdjavax.servlet/groupId artifactIdjstl/artifactId /dependency dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-jasper/artifactId scopeprovided/scope /dependency /dependencies声明war打包方式是整组配置里最关键的决定。war包可以被外部Tomcat直接解压部署JSP文件保持在/WEB-INF/jsp目录下不会被SpringBoot的打包插件重命名或跳过。tomcat-embed-jasper的provided作用域意思是编译和本地运行时需要它但打包时不需要把JSP编译器塞进war的lib目录因为外部Tomcat自带JSP引擎避免两个编译器冲突。这里还涉及一个SpringBoot版本选择问题。搜索“springboot版本太高”报错的人多半是用3.x版本跑老项目。SpringBoot 3.x把javax.servlet迁移到了jakarta.servletJSP页面里的taglib指令头也要跟着换命名空间网上大量老教程里的% taglib prefixc urihttp://java.sun.com/jsp/jstl/core %在3.x下会编译失败。如果是新写项目优先用2.7.x版本生态兼容性最稳。2.3 视图前缀、编码和文件上传的关键参数配置JSP项目排错半天找不到页面九成是spring.mvc.view.prefix和suffix没配对。视图解析器的作用是把Controller返回的字符串视图名拼接成真实的JSP文件路径。比如Controller返回user/info解析器会去/WEB-INF/jsp/user/info.jsp找文件。注意/WEB-INF/目录下浏览器无法直接访问只能通过服务端跳转进入这本身就是一层不错的页面访问控制。下面是完整的配置server.port8080 spring.application.nameorder-online spring.mvc.view.prefix/WEB-INF/jsp/ spring.mvc.view.suffix.jsp spring.mvc.view.content-typetext/html;charsetUTF-8 server.servlet.encoding.charsetUTF-8 server.servlet.encoding.forcetrue spring.servlet.multipart.max-file-size5MB spring.servlet.multipart.max-request-size10MB spring.datasource.urljdbc:mysql://localhost:3306/order_db?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai spring.datasource.usernameroot spring.datasource.passwordroot server.servlet.session.timeout30m把关键参数的作用整理成一张表方便配置时逐个对照配置项作用建议取值spring.mvc.view.prefixController返回的逻辑视图名前缀/WEB-INF/jsp/spring.mvc.view.content-type页面响应类型和字符集text/html;charsetUTF-8server.servlet.encoding.force强制请求和响应都使用指定编码truespring.servlet.multipart.max-file-size单个上传文件大小上限菜品图片常用5MBserver.servlet.session.timeoutSession空转超时时间支付流程要留足30mJSP里最容易翻车的中文乱码就是这三层不一致造成的JSP页面顶部的contentType、Spring MVC的响应编码、MySQL连接URL里的characterEncoding。任何一个地方漏掉UTF-8订单地址或菜品名就会变成问号。上面配置里server.servlet.encoding.forcetrue比较关键它保证请求体和响应体都被强制转成UTF-8不会出现只改了页面没改容器的情况。2.4 从Controller到JSP制作一个“个人信息展示页面”订餐系统里用户点击“个人中心”要同时展示用户基本信息和最近订单。这个页面用JSP做非常简单Controller查询数据放进ModelJSP用EL表达式和JSTL标签渲染。Controller的代码Controller RequestMapping(/user) public class UserController { private final UserService userService; private final OrderService orderService; public UserController(UserService userService, OrderService orderService) { this.userService userService; this.orderService orderService; } GetMapping(/info) public String info(HttpSession session, Model model) { Long userId (Long) session.getAttribute(userId); UserVO user userService.findUserById(userId); ListOrderVO recentOrders orderService.findRecentOrders(userId, 5); model.addAttribute(user, user); model.addAttribute(orders, recentOrders); return user/info; } }对应的WEB-INF/jsp/user/info.jsp文件内容% page contentTypetext/html;charsetUTF-8 languagejava % % taglib prefixc urihttp://java.sun.com/jsp/jstl/core % html body h3${user.nickname}/h3 p手机号${user.phone}/p h4最近订单/h4 ul c:forEach items${orders} varo li订单号${o.orderNo}金额${o.totalAmount}/li /c:forEach /ul /body /html这个流程里有一个细节值得注意Controller方法返回字符串user/infoSpring MVC会把它交给视图解析器处理不是直接当响应内容输出。Model里的数据会暴露给视图页面里用${user.nickname}取的是user对象的nickname属性本质是反射调用getter方法所以VO类必须有对应的getter。c:forEach是JSTL的核心标签items对应传入的List集合var声明循环变量比在JSP里写% for(...) %代码块干净得多也更容易维护。到这里SpringBoot和JSP之间的“桥”已经打通。这套配置同样适用于商品列表、订单详情的渲染后面设计核心业务模块时页面展示部分直接复用这套模式即可。3. 订餐系统核心业务模块菜单、购物车与订单状态的设计3.1 数据模型设计哪些表必须拆哪些字段必须冗余订餐系统的表结构按照“主数据”和“交易数据”两个维度来划分最清晰。主数据是用户、商家、分类、菜品交易数据是购物车、订单、订单明细、评价。最小值集如下表名核心字段作用memberid, nickname, phone, password_hash用户登录信息merchantid, name, address, business_hours商家资料categoryid, merchant_id, name菜单分组比如“热菜”“凉菜”dishid, merchant_id, category_id, name, price, stock, pic菜品和库存cartid, member_id, dish_id, quantity购物车ordersid, order_no, member_id, merchant_id, total_amount, status, pay_status, created_at订单主表order_itemid, order_id, dish_id, dish_name, dish_pic, price, quantity订单明细快照订单设计里有一条值得多花点存储换稳定性的经验明细表里冗余商家和菜品信息。比如order_item里单独存一份dish_name和dish_pic将来商家修改菜品名称、价格甚至下架菜品历史订单展示完全不受影响。如果不做这个快照订单列表每次都要关联菜品表取名称菜品一旦删除用户看到的订单页面就会是一排null。用户表的密码字段必须存哈希值推荐用BCrypt加密。很多参考项目直接在数据库里明文存密码答辩或面试时被问“密码怎么存的”会非常被动。数据库连接的工具类、测试类里也不要出现真实账号密码改成读取环境变量。3.2 下单接口为什么事务必须包住扣库存在JSP项目里用户提交订单就是一个表单POST请求。但Controller背后的OrderService.submitOrder要在一个事务里完成三件事检查并锁定菜品库存、生成订单和订单明细、清空购物车。任何一个步骤失败事务回滚数据库停留在操作前状态。核心代码如下Override Transactional(rollbackFor Exception.class) public OrderVO submitOrder(Long memberId, Long merchantId, ListCartDTO carts) { long totalAmount 0L; for (CartDTO cart : carts) { // SELECT ... FOR UPDATE锁住菜品行防止并发下单造成超卖 Dish dish dishMapper.selectByIdForUpdate(cart.getDishId()); if (dish.getStock() cart.getQuantity()) { throw new BizException(菜品库存不足 dish.getName()); } totalAmount dish.getPrice() * cart.getQuantity(); } OrderEntity order new OrderEntity(); order.setOrderNo(generateOrderNo()); order.setMemberId(memberId); order.setMerchantId(merchantId); order.setTotalAmount(totalAmount); order.setStatus(OrderStatus.WAIT_PAY.getCode()); order.setPayStatus(PayStatus.UNPAID.getCode()); orderMapper.insert(order); for (CartDTO cart : carts) { dishMapper.decreaseStock(cart.getDishId(), cart.getQuantity()); orderItemMapper.insert(fromCart(cart, order.getId())); } return OrderVO.fromEntity(order); }这段代码有两个层面保证库存正确。第一层selectByIdForUpdate对应的SQL是SELECT * FROM dish WHERE id ? FOR UPDATE在事务内锁定该菜品行其他事务要更新这一行必须等当前事务提交这是悲观锁。第二层兜底扣减库存的SQL必须写成UPDATE dish SET stock stock - #{quantity} WHERE id #{id} AND stock #{quantity}即使程序逻辑出了漏洞数据库的条件判断也会拦住超卖。Transactional(rollbackFor Exception.class)里的rollbackFor值得展开讲Spring默认只在抛出运行时异常时回滚如果业务异常继承了Exception而这里没写rollbackFor事务不会回滚订单照样入库库存却扣了。所谓java基本功问到这里基本能区分一个人是“会写SpringBoot”还是“理解SpringBoot”。3.3 订单状态机用枚举收敛状态流转订单状态是订餐系统里最容易被写乱的部分。新手常见写法是直接UpdateWrapper里set(status, 4)多条更新路径互相交叉两周后谁也说不清“已支付”到底能不能跳到“配送中”。正确做法是先画一张状态迁移表再在代码里用状态机限制流转方向。当前状态可迁移状态0 待支付1 已支付0 待支付-1 已取消1 已支付2 商家接单1 已支付5 退款2 商家接单3 配送中3 配送中4 已完成状态机的统一收口放在一个Service方法里比如orderStatusService.transit(orderId, targetStatus)进入方法第一步校验当前状态和目标状态是否存在合法迁移路径不合法直接抛异常。这样所有调用方只能通过这一个入口改状态不会出现绕过校验的强制UPDATE。还需要把“订单状态”和“支付状态”分开存字段。有的流程是货到付款订单已完成但支付状态仍然是“未支付”两个状态混在一起存成4、5、6、7这种魔法数字列表查询会写得极其痛苦。面试题里“如何设计订单状态”的隐含考点就是看能不能把“业务流程状态”和“资金流转状态”解耦。3.4 JSP里的JSON交互购物车页面怎样局部刷新很多搜索“jsp jsonarray import”的人是想在JSP页面里解析后端返回的JSON数组字符串。购物车数量加减就是一个典型场景用户点击加号页面不能整页刷新要用AJAX把菜品ID和数量发给ControllerController返回最新的JSON页面端局部更新。Controller层的接口返回JSON数据而不是视图名GetMapping(/cart/list) ResponseBody public ListCartVO listCart(Long memberId) { return cartService.findCartByMember(memberId); }带ResponseBody注解的方法返回值会由Jackson序列化成JSON字符串Spring MVC不再走视图解析器。这解决了“JSP项目里也能单独提供JSON接口”的需求。JSP页面侧的处理方式% page pageEncodingUTF-8 % div idcartList/div script fetch(/cart/list?memberId%session.getAttribute(userId)%) .then(res res.json()) .then(data { const list data.map(item trtd${item.dishName}/tdtd${item.quantity}/tdtd${item.price}/td/tr ).join(); document.getElementById(cartList).innerHTML table${list}/table; }); /script注意页面里用%session.getAttribute(userId)%直接取服务端Session值拼进URL这是JSP项目的一个优势前后端分离项目里前端要拿到当前用户ID必须调一个接口JSP里Session天然可用。fetch是现代浏览器的原生API返回的res.json()已经完成JSON解析不需要再额外JSON.parse也不需要引入jQuery就能完成局部刷新。4. 并发订餐下的数据库事务与常见部署排错4.1 锁策略悲观锁锁库存乐观锁改资料网络订餐的并发压力不在于整体QPS而集中在少数热点菜品上。比如某个限时折扣菜只剩最后一份两个用户同时点击下单代码如果按“查库存 → 生成订单 → 减库存”三步走两条线程都能查到stock1最后订单生成两份库存变成负数。解决这个问题的核心是在数据库层对库存行加锁。上一章代码里已经用到了悲观锁SELECT ... FOR UPDATE。它在事务内锁住dish表的指定行第二个事务对同一行的查询和更新会阻塞必须等第一个事务提交。这个锁的特点是安全、实现简单代价是并发时会排队。库存这种“竞争激烈、必须立刻拦截”的数据适合用它来兜底。乐观锁适用于“冲突概率低”的更新场景比如用户修改个人资料。实现方式是在表上增加一个version字段更新时把版本号作为条件UPDATE member SET nickname #{nickname}, version version 1 WHERE id #{id} AND version #{version}如果返回的影响行数为0说明更新前版本已被其他事务改过业务层选择提示“信息已变更请刷新重试”。乐观锁没有数据库锁等待在冲突少时吞吐更高但不能无脑用于库存扣减因为购物车场景的并发冲突恰恰集中在少部分热门菜品上冲突率高时乐观锁的重试反而放大数据库压力。4.2 连接池和事务边界一单别拖死整个库SpringBoot 2.x默认使用HikariCP连接池它的默认配置足够应对练习环境但生产环境需要显式控制几个参数。下面是适合订餐系统低并发起步的一组配置spring.datasource.hikari.minimum-idle5 spring.datasource.hikari.maximum-pool-size20 spring.datasource.hikari.connection-timeout30000 spring.datasource.hikari.max-lifetime1800000maximum-pool-size不是越大越好。MySQL默认最大连接数是151一个SpringBoot实例配20两台实例同时部署也才占掉40个连接要给其他后台工具留出余量。max-lifetime要小于MySQL的wait_timeout否则空闲连接被数据库主动断开后连接池还在继续使用日志里会出现Communications link failure。事务边界同样影响连接池。下单方法里只做数据库操作锁库存、插订单、插明细、减库存。短信通知、消息推送这类外部I/O操作要放在事务提交之后执行。如果把这些动作写进Transactional方法内事务会一直持有数据库连接等待外部服务响应高峰期一个慢速短信通道就能耗尽整个连接池。事务里不做远程调用这个原则写进java八股文也不为过。4.3 jsp编译class文件保存在哪里与启动报错排查JSP和普通HTML最大的不同在于JSP第一次被访问时会被容器翻译成Servlet Java源文件再编译成class。这也解释了为什么修改JSP文件后有时刷新页面看不到变化Tomcat的编译产物缓存没有失效。嵌入式Tomcat运行SpringBoot时编译产物在CATALINA_BASE/work目录下外部Tomcat部署时路径一般是TOMCAT_HOME/work/Catalina/localhost/项目名/org/apache/jsp。class文件就保存在这里的org/apache/jsp目录中排查“JSP改动不生效”时先清空这个work目录再重启。“Whitelabel Error Page”是SpringBoot默认错误页看到它说明请求已经到了SpringMVC但视图解析失败九成是spring.mvc.view.prefix配置的路径与实际JSP文件位置不一致。先确认Controller返回的视图名和WEB-INF/jsp/下文件路径是否完全对应再去查路由问题。JSP页面中文乱码则要从三层排查页面顶部contentType是否声明UTF-8Spring的CharacterEncodingFilter是否被禁用MySQL连接URL里是否带的characterEncodingutf8。还有一个容易被新版本SpringBoot坑到的点3.x版本里tomcat-embed-jasper的Servlet API命名空间换成了jakarta.*旧的JSP标签库如果还引java.sun.com/jsp/jstl/core会编译失败。项目升级前建议先在本地起一个环境验证JSP和JSTL兼容性再动代码。4.4 JSP页面离开提示与基础安全收口订餐后台的商家经常在编辑菜品信息时误关标签页。JSP页面里可以注册beforeunload事件在表单未保存时弹出离开确认但直接给所有页面都挂beforeunload会非常烦人因为每次刷新都会弹窗。改进做法是用一个“脏标记”变量控制script let dirty false; document.getElementById(dishForm).addEventListener(input, () { dirty true; }); window.addEventListener(beforeunload, (e) { if (dirty) { e.preventDefault(); e.returnValue ; } }); /script用户输入过内容后才把dirty置为true没有修改直接关闭页面不会打断操作。e.preventDefault()和e.returnValue 两者配合保证Chrome和Firefox都弹确认框。安全这块JSP项目因为是服务端渲染XSS防护容易疏忽。用户昵称、菜品名这类数据不需要展示富文本直接用JSTLc:out输出它会默认转义HTML。SQL注入统一用MyBatis的#{}预编译占位符禁止用${}拼接字符串。下单接口的入参校验检查“菜品是否属于该商家”防止用户传一个merchantId就替别的商家下单这个细节经常作为java面试题出现在项目询问环节。5. 订餐系统上线前的验证、压测与配置收口5.1 用curl模拟一次完整点餐流程服务端本地启动后用curl走一遍“登录 → 加购 → 下单”确认接口链路通顺。注意登录接口通常设置了会话Cookie后续命令要用同一个Cookie文件保持登录态curl -c cookies.txt -X POST http://127.0.0.1:8080/login \ -d phone13800000000password123456 curl -b cookies.txt -X POST http://127.0.0.1:8080/cart/add \ -d dishId3quantity1 curl -b cookies.txt -X POST http://127.0.0.1:8080/order/submit \ -d merchantId1-c表示把服务端返回的Cookie写入文件-b表示发送请求时从文件读取Cookie。下单接口返回200后直接查orders和order_item两张表确认数据落库订单状态应为“待支付”的0这个验证比看页面反馈更可靠。5.2 用wrk压一下菜品列表接口别只看吞吐量上线前用wrk对只读的菜品列表接口做一分钟压测能快速发现连接池、线程池的明显瓶颈。压测POST类下单接口前要确认CSRF和登录校验已经关闭或做了白名单wrk -t4 -c50 -d30s http://127.0.0.1:8080/dish/list?merchantId1-t4开四个线程、-c50保持50个并发连接、-d30s持续30秒。输出结果里关注的不是Requests/sec有多高而是Latency分位数P99超过500ms就说明有线程阻塞或SQL慢查询。同时观察数据库的连接数监控如果连接数被打满优先排查是否有事务没提交。5.3 上线前检查清单照着做一遍最后按这张表逐项收口比反复浏览页面更有效检查项操作方式JSP热部署关闭生产环境关闭spring.devtools.restart.enabled避免JSP修改触发频繁重启慢SQL日志打开MySQL的slow_query_log设long_query_time1数据库账号应用连接账号单独创建只授权业务库不直接使用root配置文件敏感信息application.properties中不放密码用环境变量或配置中心注入最后一道工序是给菜品的主要页面做一次“预热”。JSP的首次访问会触发编译耗时可能达到几秒用户点击首页时恰好踩中这次编译体感就是“系统很卡”。用wget或curl把菜品列表、搜索结果、订单详情这几个高频入口在发布后立即请求一遍让JSP完成预编译真实用户访问时直接从编译产物渲染。这套订餐系统的上线准备到这一步才算真正完毕。本文还有配套的精品资源点击获取
)
)
