Java后端项目实战：Servlet+Vue前后端分离外卖平台全流程

简介这份资源是一套前后端分离的饿了么平台后端项目前端采用 Vue.js后端基于 Servlet并通过 AJAX 完成异步数据交互适合正在学习 Java Web、Vue 基础或前后端分离开发的初学者与课程设计者。内容覆盖用户登录、商品查询、订单处理等典型业务并涉及 JSON 数据交换、RESTful API、MVC/MVVM 架构、数据库操作及 JWT 安全验证等关键知识点。压缩包共 131 个文件包含 Java 源码、编译后 class 文件、Vue 前端页面、HTML 页面、CSS/LESS/SCSS 样式、JavaScript 脚本及 XML 配置等整体 4.15MB结构小巧便于快速下载与本地部署。目前已有 1435 人学习下载适合用于理解前后端分离开发流程、Servlet 接口设计与页面交互实现。通过项目源码与配置文件可直观掌握从工具类编写到登录逻辑、AjaxServlet 响应处理的完整实现思路是 Java Web 课程设计与入门实战的参考案例。1. 拿到这份Java后端项目先别急着跑ServletVue前后端分离到底在练什么这份Java后端项目写的是“某外卖平台”打开一看技术栈是Servlet Vue AJAX没有Spring Boot却把前后端分离的链路完整走了一遍。拿到资源如果直接跑起来多半会在第一个AJAX请求就卡住不是端口连不上就是返回的中文变成问号。它解决的问题很具体前端页面Vue通过异步请求调用后端接口Servlet后端以JSON返回商家、菜品、购物车与订单数据最后组成一个可下单的外卖业务闭环。适合的人群也比较明确——想练Java Web基础、需要一份能写进简历的就业项目、或者正在补Servlet和AJAX之间数据流转经验的同学。整条接口设计和请求流程值得照着敲一遍新手能跟着跑通熟手也能翻出不少细节问题。2. 项目结构拆解某外卖平台的Servlet后端与Vue前端五个模块一次理清2.1 后端包结构Servlet做Controller业务分组而不是类爆炸老式Java Web项目最常见的写法是一个页面配一个Servlet登录就建LoginServlet注册就建RegisterServlet功能多了以后class文件越来越多改一个业务逻辑要翻四五个Servlet。模拟项目X的做法更收敛后端按业务分成controller、service、dao、entity、util五个包controller包下一个业务模块只保留一个Controller所有接口通过action参数区分整体目录大概长这样project-x/ ├── src/main/java │ ├── com.example.controller │ │ ├── BaseServlet.java │ │ ├── SellerController.java │ │ └── OrderController.java │ ├── com.example.service │ ├── com.example.dao │ ├── com.example.entity │ └── com.example.util ├── src/main/resources │ └── db.properties └── webapp/WEB-INF/web.xml这个结构里controller负责接收请求service承载业务判断dao封装JDBC查询entity对应数据库表util放JSON转换、数据库连接和token生成工具。因为没引入Spring框架对象都是需要哪个就new哪个这条路虽然不够“优雅”但每一步依赖关系都看得见比直接上Spring Boot更容易理解Servlet生命周期以及request、response的作用范围。从调试角度看这种结构也比框架项目直观。请求进来之后在BaseServlet里打断点能看到完整的请求头、参数、session信息再往下走一步能看清service和dao之间是怎么传参的。如果直接打开一个Spring Boot项目看Controller参数绑定、异常处理、JSON序列化全被框架藏起来新手会以为后端就是“写个方法返回对象”这么简单。2.2 前端目录规划Vue页面、Axios封装与路由划分前端部分由Vue CLI搭建里面比较重要的是api目录和router目录。api目录下把每个后端接口封装成一个函数组件里不直接拼URLrouter目录负责页面跳转和路由守卫。常规拆分如下src/ ├── api/ │ ├── http.js │ ├── seller.js │ ├── order.js │ └── user.js ├── views/ │ ├── Login.vue │ ├── SellerList.vue │ └── Cart.vue ├── router/ └── store/api抽取的好处是将来后端路径调整时只需要改api目录里的约定不用翻遍每个Vue组件。router里加一个登录守卫没有token就跳回登录页这种基础登录控制在前端单页应用里非常常见。页面上只关心调用哪个函数、拿到的数据长什么样不关心接口到底请求了哪个URL前后端分工就清晰了。值得注意的是这个前端项目不依赖任何重型UI框架页面用原生CSS加组件化写法就能撑起来。这其实是好事你在调接口的时候不会被Element UI的表单校验逻辑干扰返回的每一条JSON都能直观地渲染到页面上。2.3 数据库表设计商家、菜品、购物车与订单的关联关系外卖业务的核心表是商家、菜品、购物车和订单模拟项目X用最直接的外键关系把它们串起来表名关键字段作用t_userid, phone, password用户登录t_sellerid, name, address, delivery_fee商家信息t_foodid, seller_id, name, price, pic菜品信息t_cartid, user_id, food_id, quantity购物车明细t_orderid, order_no, user_id, total_price, status订单主表关联关系不复杂商家一对多菜品用户和菜品通过购物车表做多对多用户一对多订单。这样的表结构对练手足够订单明细表没有拆出来是合理的简化等把主链路跑通之后再扩展。需要注意t_food里的seller_id就是t_seller的id前端菜品列表接口拿到的就是商家ID不需要再join回商家表去查名字数据量小的时候直接拼一个商家的name字段也行。建表时还有个细节t_user里的phone字段建议加唯一索引用户名密码逻辑经常会把手机号作为登录账号t_order的status字段用TINYINT0代表待支付1代表已完成不要在数据库里存中文状态接口返回时再映射就好。2.4 前后端通信AJAX请求全流程与JSON响应约定整个请求流程走的是标准前后端分离链路Vue页面触发事件 → Axios发送POST请求 → Tomcat接收后交给Servlet → Servlet调用service查库 → 结果用JSON工具类转成字符串 → response输出JSON → Axios响应拦截器解析 → Vue页面刷新数据。后端返回的JSON格式在项目里是统一的类似{ code: 200, message: OK, data: { sellerId: 3, sellerName: 某湘菜馆, deliveryFee: 3.0 } }code为200约定为业务成功非200时前端统一弹出message里的错误描述业务数据放在data里。这个约定看似简单但省去了每个接口单独商量返回结构的麻烦前端响应拦截器只判断一次code字段就够了。通信格式上还有个小规矩必须约定好请求参数怎么传。项目里绝大多数接口用POST参数可以放form表单也可以放JSON body但同一个项目中只应该选一种。模拟项目X的登录和列表接口用form参数下单接口用JSON body类型切换时后端接收方式完全不同这个细节在第4章会单独讲。2.5 选型理由为什么是Servlet而不是Spring Boot很多人会问现在企业里都上Spring Boot了为什么还拿Servlet做后端。我的看法是这个资源的目的不是炫技而是把请求进来之后发生的事讲清楚。Spring Boot里Controller接收请求、参数绑定、异常处理和JSON序列化都已经被框架处理掉了初学者只看到方法返回一个对象至于HTTP状态码怎么设置、响应编码在哪里生效完全是黑匣子。Servlet手写时这些步骤全都要自己控制一次响应设置错误立刻就能看到后果。等Servlet版本跑通再去看Spring Boot的DispatcherServlet会发现Spring Boot只是把这些事封装得更好底层原理并没有变。所以这份资源适合作为Java Web入门后的第一个完整项目而不是替代Spring Boot的学习。建议两条线并行先用Servlet资源把请求流转练熟再对照Spring Boot的注解理解封装关系面试时被问到“一个请求从浏览器到数据库经历了什么”你可以讲得比框架使用者细好几个层级。3. 从零初始化到跑通第一个接口版本组合、Tomcat运行、Vite代理与SQL导入3.1 环境版本组合JDK8、Tomcat8.5、MySQL5.7、Node14这个项目涉及的环境不少我一般在类似项目上用这一套组合互相兼容性最好组件推荐版本说明JDK1.8和Tomcat兼容最稳老项目基本都编译在1.8Tomcat8.5或9.x支持Servlet 3.1规范与WebServlet注解MySQL5.7或8.0建库时注意字符集统一utf8mb4Node14 LTS或16 LTS配合Vue CLI 4/5使用为什么不用JDK17因为项目里用到的部分老依赖在新JDK下会碰到反射访问限制报错排查起来很消耗耐心完全没必要在环境上浪费时间。如果你本机装了多个JDK版本记得在开发工具里把项目SDK和语言级别全部指到1.8只改一处很容易出现编译版本不一致的诡异问题。3.2 后端导入与运行配置war包和Tomcat启动后端拿到手之后先检查是不是Maven结构。如果是直接用开发工具打开根目录的pom.xml等待依赖下载完成。这里有一个容易漏掉的地方pom.xml里通常配了Tomcat插件可以直接通过Maven命令启动我一般会用插件方式省去手动下载Tomcat再配置的步骤plugin groupIdorg.apache.tomcat.maven/groupId artifactIdtomcat7-maven-plugin/artifactId version2.2/version configuration port8080/port path//path uriEncodingUTF-8/uriEncoding /configuration /plugin这个插件的port参数指定后端服务端口path指定上下文路径。path设成“/”表示直接通过根路径访问接口如果设成“/project-x”那么所有接口URL都要多出一层前缀。uriEncoding设成UTF-8解决POST参数的中文乱码问题。启动命令是mvn tomcat7:run启动后后端接口地址就是http://localhost:8080/api/xx。如果你坚持用手动配置Tomcat的方式也可以把项目打包成war包丢进Tomcat的webapps目录。要注意war包的名字就是访问路径假设改成“project-x.war”接口地址就变成http://localhost:8080/project-x/api/xx前端代理配置要跟着改不然请求全部404。3.3 前端代理配置vue.config.js里跨域开关前端项目一般在8081端口下运行后端在8080浏览器认为这是跨域请求直接访问会被拦截。开发阶段的解决办法是在vue.config.js里配devServer代理module.exports { devServer: { port: 8081, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } };这段配置的意思是前端请求中凡是路径以/api开头的都转发给http://localhost:8080处理。port是前端页面的端口target是后端服务地址changeOrigin设为true会把请求头里的Host字段改写成target的域名后端不会因为来源不同而拒绝请求。代理只解决开发阶段的跨域。上线时前端要执行npm run build生成静态文件放进Tomcat的webapps目录和后端同源部署请求同一个域名同一个端口下就不再跨域。如果你在开发环境直接双击index.html打开页面代理不生效接口会404这个要特别注意。3.4 数据库初始化和示例数据编写数据库部分通常会给一个SQL文件没有的话自己建也行。核心表结构和示例数据长这样CREATE TABLE t_seller ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50) NOT NULL, address VARCHAR(255), delivery_fee DECIMAL(5,2) DEFAULT 0 ); INSERT INTO t_seller(name, address, delivery_fee) VALUES (某湘菜馆, 某路12号, 3.00), (某沙县小吃, 某街88号, 2.00); CREATE TABLE t_food ( id INT PRIMARY KEY AUTO_INCREMENT, seller_id INT NOT NULL, name VARCHAR(50), price DECIMAL(6,2), pic VARCHAR(255) );执行SQL之前先执行set names utf8mb4;再注意连接串上的characterEncoding参数比如jdbc:mysql://localhost:3306/project_x?characterEncodingutf8。如果数据库、SQL文件、连接串三个地方的字符集不统一最容易出现的现象是页面显示正常但通过命令行看数据是乱码。3.5 启动顺序与第一个AJAX请求验证我第一次跑这类项目时习惯按下面顺序来能省下大量排错时间先启动MySQL确认3306端口能连上执行一条select 1;验证。再启动后端Tomcat看控制台有没有报错用浏览器直接访问http://localhost:8080/api/seller/list如果能返回JSON说明后端正常。然后启动前端npm run serve打开http://localhost:8081登录页面能显示出来。最后打开浏览器开发者工具切到Network面板登录后看/api/user/login和/api/seller/list两个请求是否返回200。按这个顺序就算前端页面报错也能立刻判断是后端问题还是代理问题。最忌讳一上来就点页面报错了不知道在哪一层。4. 核心代码实战Servlet统一分发、Token登录、Axios封装与下单接口解析4.1 BaseServlet统一分发一个Servlet处理一个模块后端代码里最值得先读的是BaseServlet它把/api/*的请求全部收口统一处理后面的业务Controller只需要暴露具体方法WebServlet(/api/*) public class BaseServlet extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws IOException { String uri req.getRequestURI(); String action uri.substring(uri.lastIndexOf(/) 1); resp.setContentType(application/json;charsetUTF-8); switch (action) { case login: userService.login(req, resp); break; case list: sellerService.list(req, resp); break; default: resp.getWriter().write({\code\:404,\message\:\接口不存在\}); } } Override protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws IOException { doPost(req, resp); } }这段代码里最关键的是最后的doGet也调用doPost否则用GET请求访问列表接口时不会进入任何业务逻辑。action参数通过URL最后一段路径提取/api/user/login取到login/api/seller/list取到list这样每个模块的Controller只需要在BaseServlet里登记自己的方法名。参数说明switch分发是简化写法方法多了以后可以改成反射调用但练手阶段switch最直白不会因为加大反射复杂度导致排查困难。4.2 登录接口与Token流程session为什么会被放弃前后端分离项目里最常出现的问题是“登录状态保不住”原因是session默认存服务端、依赖Cookie传递sessionId而前后端分离时Cookie跨域是个大麻烦。模拟项目X的登录接口采用的是token方案public void login(HttpServletRequest req, HttpServletResponse resp) throws IOException { String phone req.getParameter(phone); String password req.getParameter(password); User user userDao.findByPhone(phone); if (user ! null user.getPassword().equals(password)) { String token TokenUtil.create(user.getId()); resp.getWriter().write(Result.success(token)); } else { resp.getWriter().write(Result.fail(401, 手机号或密码错误)); } }登录成功后会生成一个token字符串返回给前端前端把它存进localStorage之后每个请求都带着这个token去证明身份。TokenUtil.create里一般会把用户id和一个过期时间戳拼在一起做加密生成规则不复杂但必须保证服务端能解开。参数说明这里用的是getParameter方式读取参数说明前端提交的是form表单如果前端用JSON body提交这里会取不到phone后面4.5小节单独处理。4.3 商家列表和菜品列表POST参数与返回格式列表类接口在项目里占大头常见接口约定如下接口请求方式参数返回内容/api/seller/listPOST无code商家数组/api/food/listPOSTsellerIdcode菜品数组/api/cart/infoPOSTuserId购物车明细为什么列表接口不用GET而用POST原因有两个第一统一走BaseServlet的doPost分发省去doGet和doPost两套逻辑第二避免参数直接出现在URL里GET方式传参在浏览器历史记录里留下完整地址容易泄漏。POST参数拿到之后用JSON工具类转成字符串写回response例如ListSeller sellers sellerDao.findAll(); resp.getWriter().write(Result.success(sellers));Result.success内部把data字段转成JSON字符串再拼上code和message。到这里你应该能理解为什么后端返回统一结构那么重要——列表接口、详情接口、下单接口各自返回不同数据结构但最外面那层判断始终是code前端处理起来很轻松。4.4 前端Axios封装baseURL、拦截器与错误处理前端入口是api目录下的http.js所有请求都从这里发出不在组件里直接new Axiosimport axios from axios; const http axios.create({ baseURL: /api, timeout: 5000 }); http.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers.Authorization Bearer token; } return config; }); http.interceptors.response.use( res { if (res.data.code 200) { return res.data.data; } return Promise.reject(new Error(res.data.message)); }, err { if (err.response err.response.status 401) { window.location.href /login; } return Promise.reject(err); } );baseURL设成/api组件里调用http.post(/seller/list)实际请求路径就是/api/seller/list。请求拦截器负责把token塞进请求头约定格式为“Bearer ”加token后端解析时要按这个前缀切割。响应拦截器统一拆包code为200时只返回data非200直接抛错组件里所有接口的成功回调拿到的都是干净的data对象不需要每个页面都判断一次code。401状态码则强制跳登录页避免用户停留在失效页面。4.5 下单接口的JSON body解析不要再读getParameter登录和列表接口用的是form参数下单接口却换成了JSON body提交这是项目里最容易翻车的地方。前端下单时提交的数据类似{ userId: 1, items: [ { foodId: 101, quantity: 2 } ], remark: 少放辣 }后端接收JSON body时不能再调用req.getParameter(userId)而是要主动读取请求流的body再解析成Java对象BufferedReader reader req.getReader(); StringBuilder body new StringBuilder(); String line; while ((line reader.readLine()) ! null) { body.append(line); } JSONObject obj JSON.parseObject(body.toString()); JSONArray items obj.getJSONArray(items);req.getReader()拿到的是请求体字符流JSONObject.parseObject把整个JSON字符串转成可操作的对象。参数说明userId是外层字段先解析出来items是数组遍历后逐条取foodId和quantity再分别插入订单明细或生成订单主表记录。如果这一步还在用getParameter拿到的永远是null而且不会报任何异常适合作为排查逻辑问题的重点怀疑对象。5. 避坑与常见问题跨域拦截、中文乱码、登录态丢失、端口冲突与4045.1 跨域报错代理写了但请求仍被浏览器拦截现象前端页面打开正常Network里的请求显示CORS error控制台提示No Access-Control-Allow-Origin header is present。原因最常见的是直接用浏览器地址栏访问了http://localhost:8080/api/xx而不是通过前端代理访问。地址栏直接访问时没有经过webpack-dev-server代理浏览器发现8080端口与前端页面的8081端口不同执行了同源策略拦截。解决先确认页面是通过http://localhost:8081打开的再看Network里的请求URL是不是/api/xx开头。如果坚持前后端分开部署后端需要加一个CORS过滤器统一放行WebFilter(/*) public class CorsFilter implements Filter { public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletResponse resp (HttpServletResponse) response; resp.setHeader(Access-Control-Allow-Origin, http://localhost:8081); resp.setHeader(Access-Control-Allow-Methods, POST, GET, OPTIONS); resp.setHeader(Access-Control-Allow-Headers, Content-Type, Authorization); chain.doFilter(request, response); } }这个过滤器不能滥用*通配符尤其当请求头带Authorization时通配符会导致某些浏览器直接拒绝。Allow-Headers里必须显式声明Authorization和Content-Type否则带token的请求还是会被拦。5.2 中文乱码JSON返回问号的三个排查点现象Postman请求接口返回数据正常浏览器页面里显示的中文全部变成了???或ç³»更诡异的是部分接口正常部分接口乱码。原因乱码出在三个环节——response输出编码、request参数编码、数据库连接编码。我见过最深的一次是三个地方都没设编码页面里商家名字全是问号排查了一整个下午。解决response的编码设置必须在调用getWriter()之前执行顺序反了不生效resp.setContentType(application/json;charsetUTF-8); resp.setCharacterEncoding(UTF-8);注意第一行设置ContentType时已经带了charset第二行是保险写法。request参数乱码时在BaseServlet的doPost开头加一行req.setCharacterEncoding(UTF-8);确保getParameter读出来的参数是UTF-8。数据库连接串上补characterEncodingutf8建库时用DEFAULT CHARSETutf8mb4。检查顺序从输出端开始先用Postman确认接口返回是否乱码再确认页面渲染最后排查数据库避免来回折腾。5.3 登录状态丢失Session在前后端分离下的局限现象登录成功后页面跳转正常按F5刷新一下又回到登录页或者某个接口调用时后端报session为null。原因项目一部分接口还在用request.getSession()另一部分已经换成token两部分互相不认账。Session依赖浏览器自动携带Cookie跨端口、跨域环境下Cookie传不过去session在每次刷新时都可能是新的登录状态自然保不住。解决统一改成token方案登录接口返回token前端存在localStorage请求拦截器统一加到Authorization头后端写一个拦截器或过滤器校验token。校验通过后把用户信息放进request的attribute里后续接口从attribute取当前用户不再依赖session。String auth req.getHeader(Authorization); if (auth null || !auth.startsWith(Bearer )) { Result.fail(401, 未登录); return; } String token auth.substring(7); User user TokenUtil.parse(token); if (user null) { Result.fail(401, 登录已过期); return; } req.setAttribute(currentUser, user);这里最坑的一点是headername大小写HTTP头名称不区分大小写getHeader(Authorization)和getHeader(authorization)都能取到但如果前端在拦截器里设置时把key写错了后端看到的就是null。各端两边的key写对否则反复排查都是浪费时间。5.4 Tomcat端口被占用与上下文路径对不上现象启动后端时报Address already in use: JVM_Bind :8080或者明明写了WebServlet(/api/seller/list)访问却返回404。原因端口被占用是8080被本地另一个进程抢占了换成8088后控制台不报错但前端代理还指向8080。404的情况则是war包部署时上下文路径带了名字实际URL多了一层。解决改Tomcat端口时用编辑器打开conf/server.xml找到Connector port8080改成8088不能只改一个地方。Maven插件方式则改pom.xml里的port节点。前端代理的target同步改成http://localhost:8088。上下文路径方面插件方式path//path表示没有前缀手动部署时war包叫什么名字URL上就要带什么前缀前端baseURL或代理规则要重新写。5.5 接口404注解扫描、编译产物和Artifacts配置现象代码里明明有WebServlet(/api/user/login)启动Tomcat后访问却404控制台也没有加载这个Servlet的日志。原因典型的是web.xml里的metadata-completetrue导致容器不扫描注解只能通过web.xml显式声明Servlet另一种是IDE打war包时没把编译后的class文件打到WEB-INF/classes目录Servlet类根本没进最终产物。解决先看web.xml头部web-app xmlnshttp://xmlns.jcp.org/xml/ns/javaee xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance metadata-completefalsemetadata-complete一定是false才能通过WebServlet注解注册。然后检查编译输出目录确认target/classes里有对应的Servlet.class文件。IDE方式启动时还要检查Artifacts里有没有把classes目录加进去否则代码编译成功但运行环境看不到。判断依据很简单去看Tomcat部署后的实际目录结构如果WEB-INF/classes下面没有你的包结构那就不是代码问题是打包问题。6. 验证技巧统一Result返回结构用curl快速核对后端接口6.1 统一返回结构用code判断成败前端少一半逻辑这份资源把所有接口的返回都统一成了Result对象这个设计值得保留到日常开发里public class Result { private int code; private String message; private Object data; public static Result success(Object data) { Result r new Result(); r.code 200; r.message OK; r.data data; return r; } public static Result fail(int code, String msg) { Result r new Result(); r.code code; r.message msg; return r; } }code只占用200表示成功401表示登录失效业务校验失败统一用400。别把业务错误码设计得像HTTP状态码一样复杂前端只需要判断成功和失败两种状态失败时把message直接弹出来就好。code含义越少前端响应拦截器的逻辑就越简单。6.2 curl验证法绕过浏览器直接测后端前后端联调之前我习惯先用curl把后端接口全部跑一遍确认后端没问题再开浏览器避免把跨域、代理、页面渲染问题混在一起排查curl -X POST http://localhost:8080/api/seller/list \ -H Content-Type: application/json;charsetUTF-8 curl -X POST http://localhost:8080/api/user/login \ -d phone13800138000password123456第一条命令验证列表接口返回的JSON结构第二条验证登录接口的form参数解析。关键参数解释-X POST指定请求方式-H设置请求头-d传请求体。如果返回的是完整JSON而不是404或500基本可以认定后端服务、数据库、Servlet映射都没问题剩下的事就是开前端页面验证AJAX链路。从那以后我每次接手类似的前后端分离资源都会先跑一圈curl确认后端接口返回再开前端联调避免把问题全堆在浏览器里查。这个习惯帮我省掉了大量“前端报错但后端其实没事”的排查时间希望帮到你。本文还有配套的精品资源点击获取