1. 项目概述与需求拆解1.1 这是个什么项目看到这个标题我猜不少人第一反应是这就是个典型的毕业设计选题。确实SSM Vue的组合在近年来已经成了高校软件工程类项目的事实标配但真正把它做好、做完整并不是把框架搭起来跑个Hello World那么简单。这个项目是面向青岛市城阳小饰品城开发的电商类网站。业务背景理解起来很直接小饰品城是一个线下批发与零售并存的商圈有大量商户和商品需要一个线上展示与交易窗口。系统要覆盖两类用户——普通消费者在网站上看商品、搜商品、加购物车、下订单后台管理人员维护商品信息、处理订单、管理分类、发布公告。这种模式行业内叫 B2C 轻电商跟全品类的京东、天猫比它的业务深度要浅一些但该有的核心链路一条不少。1.2 解决的核心问题是什么这类网站要解决的实际问题可以归纳成三个层面第一信息展示的线上化。小饰品城线下档口多、商品更新快消费者靠逛很难准确找到店铺和商品网站需要提供分类浏览和关键词检索能力让“找货”这件事变高效。第二交易流程的线上化。用户选完商品后要在网上下单订单进入后台管理员审核处理用户能查看订单状态。整个流程从线下口头的买卖变成系统留痕的交易闭环。第三运营管理的集中化。后台不是简单的商品发布工具还涉及库存管理、分类调整、轮播图维护、公告通知、用户管理等一系列运营动作。1.3 技术选型的现实考量SSM 指的是 Spring SpringMVC MyBatis 三件套。这套技术在 Java 服务端领域虽然有了更年轻的替代品但它依然是无数项目的基石而且学习资料、问题排查经验极其丰富对于需要一个完整项目经验的人来说非常合适。前端选 Vue是因为它组件化开发、数据驱动视图的特点非常适合商城这类交互密集型的页面。商品列表、商品详情、购物车、结算页这些功能如果用传统模板引擎做往往是后端拼字符串前端调样式开发和维护都累。用 Vue 做前后端分离后端只提供 JSON 数据接口前端负责渲染和交互分工明确。提示不要把“SSM 过时了”当成不选它的理由。一个项目的价值不在框架新旧在于业务链路是否完整、代码结构是否清晰。面试官关心的往往是你是否真的理解这套架构而不是你用了多新的框架。2. 业务模块划分与数据库设计2.1 功能模块全景做项目第一步千万别急着写代码先把模块边界画清楚。我通常会用一个简单的功能清单来约束需求范围前台用户端注册登录、商品分类浏览、商品搜索、商品详情、购物车、订单提交、个人中心订单列表、地址管理后台管理端管理员登录、商品分类管理、商品管理、订单管理、用户管理、公告管理、轮播图管理这套功能对应了一个电商系统的最小完备集。购物车和订单是交易主干分类和搜索是商品检索主干后台管理则承接运营侧的日常操作。没有加入支付、物流跟踪这类复杂度很高的子系统这是正确的取舍——项目体量要匹配实际周期和精力。2.2 核心表结构设计数据库设计是这类项目的定盘星表结构一旦定错后面写代码会非常痛苦。我自己习惯把核心表设计成下面这样表名用途关键字段user用户表id, username, password, nickname, phone, avatar, create_timecategory商品分类表id, name, parent_id, sort_ordergoods商品表id, category_id, name, subtitle, main_image, price, stock, sales, detailcart购物车表id, user_id, goods_id, quantity, checked, create_timeorder订单表id, order_no, user_id, total_price, status, receiver_name, receiver_phone, receiver_address, create_timeorder_item订单项表id, order_id, goods_id, goods_name, goods_image, price, quantityannouncement公告表id, title, content, publish_timebanner轮播图表id, image_url, link_url, sort_orderadmin管理员表id, username, password2.3 表设计中的关键决策点有几个设计决策值得展开讲讲。商品表里的分类字段为什么只存 category_id不冗余分类名称因为通过关联查询可以拿到分类名冗余反而会造成数据不一致。但 order_item 表里我刻意冗余了 goods_name 和 goods_image原因也很简单订单生成后商品信息可能被管理员修改甚至删除订单表里如果只存 goods_id用户查看历史订单时就会拿到已经变化的数据甚至查不到商品。订单需要的是交易发生那一刻的快照这是电商系统的通用设计惯例。订单表的状态字段我推荐用数字枚举而不是字符串。比如 0 表示待处理、1 表示已确认、2 表示已完成、3 表示已取消。数字存储占用小、查询排序方便配合 Java 端的枚举类做映射代码可读性也不差。商品表里专门留了 sales 销量字段这个字段别看简单它支撑了前台“销量排序”的查询逻辑也在商品列表页实现了一个小的“热销推荐”模块。顺序是后台管理员每处理完一个订单就把订单里的商品销量累加到 goods.sales 上保证销量数据的近似实时。2.4 SQL 初始化与造数据表结构设计完之后一定要写一套完整的初始化 SQL包含建库、建表、基础数据三部分。基础数据至少要包括若干测试用户、一条管理员账号、五个左右的分类项链、手链、耳饰、发饰、戒指等、每个分类下十条以上商品、一两条公告和轮播图。很多人在这个环节偷懒只建表不造数据等写完了前后端联调的时候才发现页面空空如也视觉效果和功能验证都很受影响。我给的建议是造数据的动作跟设计表结构同步完成商品图片可以先从图床或者本地静态资源里找一批示例图不用过度纠结图片完美度但数量一定要够——一套合理的演示数据对整个开发过程的帮助非常明显。3. 后端 SSM 框架核心技术实现3.1 项目结构与分层规范后端工程建议用 Maven 做标准的多模块单工程结构虽然项目规模不算大不需要真正拆多个 Maven Module但包结构一定要清晰。我推荐的包划分com.zhenpin.smallmarket ├── controller // 控制层接收请求、返回JSON ├── service // 业务层接口 │ └── impl // 业务层实现 ├── dao // MyBatis的Mapper接口 ├── entity // 实体类 ├── vo // 视图对象对接前端展示 ├── common // 通用类统一返回结果、异常处理、工具类 └── config // 配置类拦截器、跨域等分层的好处在于每个请求的路径是固定的Controller 接参数 - Service 做业务处理 - Dao 访问数据库。出了问题能快速定位在第几层而不是在一堆类里大海捞针。3.2 统一返回结果与全局异常处理这是很多项目容易忽略但必须有的设计。我见过不少项目Controller 返回值一会儿是 String一会儿是 Map一会儿直接返回实体类前端拿到数据还得猜格式。这非常影响联调效率。建议定义一个统一的 Result 类包含 code、message 和 data 三个字段所有接口的返回结构都是一样的public class ResultT { private Integer code; // 200表示成功500表示失败 private String message; // 提示信息 private T data; // 业务数据 public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT fail(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }配合 ControllerAdvice 做全局异常处理把业务异常和未知异常统一拦截Controller 里就不用到处写 try-catch 了代码会干净很多。这个习惯在任何 Java Web 项目里都值得保持。3.3 核心业务接口清单前端需要的后端接口我按业务模块整理了一份清单开发的时候照着这个表逐项补全不容易遗漏模块接口路径功能说明用户POST /api/user/register用户注册用户POST /api/user/login用户登录用户GET /api/user/info获取当前用户信息商品GET /api/goods/list商品分页列表支持分类、关键词过滤商品GET /api/goods/detail/{id}商品详情购物车GET /api/cart/list查询购物车购物车POST /api/cart/add加入购物车购物车POST /api/cart/update修改数量购物车POST /api/cart/delete删除购物车项支持批量订单POST /api/order/create提交订单订单GET /api/order/list当前用户的订单列表订单POST /api/order/updateStatus更新订单状态后台用管理POST /api/admin/login管理员登录管理GET /api/admin/goods/list后台商品管理列表管理POST /api/admin/goods/save新增/修改商品管理DELETE /api/admin/goods/{id}删除商品管理GET /api/admin/order/list后台订单列表管理GET /api/admin/stats仪表盘统计数据接口路径规范很重要前后端分离项目最怕的就是接口约定不清晰。路径里用复数名词表示资源HTTP 方法表示动作这虽然是 REST 风格的皮毛但比乱写接口要规范太多。3.4 MyBatis 的 SQL 编写要点MyBatis 是这个框架组合里最需要基本功的一环。很多同学的 SQL 写得很粗糙只会在单表上做简单的 select、insert、update。但商城项目里的业务查询多表关联和动态 SQL 是很常见的需求。商品列表的分页查询就是一个典型场景。前端传过来 categoryId、keyword、pageNum、pageSize 四个参数对应的 Mapper 写法是这样的select idselectGoodsPage resultTypecom.zhenpin.smallmarket.vo.GoodsVO SELECT g.id, g.name, g.subtitle, g.main_image, g.price, g.sales, c.name AS category_name FROM goods g LEFT JOIN category c ON g.category_id c.id where if testcategoryId ! null AND g.category_id #{categoryId} /if if testkeyword ! null and keyword ! AND g.name LIKE CONCAT(%, #{keyword}, %) /if /where ORDER BY g.sales DESC LIMIT #{offset}, #{limit} /select动态 SQL 的 where 标签帮我们解决了条件拼接时多余的 AND 和 WHERE 问题这是 MyBatis 的经典用法。LEFT JOIN 关联分类表是为了在前端商品列表上直接展示分类名称避免前端再发起第二次请求。分页这里我特意用的 LIMIT #{offset}, #{limit}因为简单直观、易于控制。也可以用 PageHelper 这类分页插件但我不建议在这个项目里引入——手写分页能让你真正理解分页的原理而且代码量并不大面试的时候还能把底层逻辑讲清楚。3.5 下单流程的事务控制订单创建是整个后端最需要严谨对待的业务逻辑因为涉及多张表的写操作生成订单、生成订单项、清空购物车、扣减库存、累加销量。任何一个步骤失败都会造成数据不一致所以事务控制是刚需。核心逻辑大致如下Override Transactional(rollbackFor Exception.class) public Order createOrder(Long userId, Long addressId, ListLong cartIds) { // 1. 查询购物车选中的商品项 ListCart cartList cartMapper.selectByIds(userId, cartIds); if (cartList null || cartList.isEmpty()) { throw new BusinessException(购物车中没有选中的商品); } // 2. 计算总价并生成订单 Order order new Order(); // 生成订单号时间戳 用户id后四位 随机数 String orderNo String.valueOf(System.currentTimeMillis()) String.format(%04d, userId) String.valueOf((int)(Math.random() * 900) 100); order.setOrderNo(orderNo); BigDecimal totalPrice BigDecimal.ZERO; for (Cart cart : cartList) { Goods goods goodsMapper.selectById(cart.getGoodsId()); totalPrice totalPrice.add(goods.getPrice().multiply( BigDecimal.valueOf(cart.getQuantity()))); } order.setTotalPrice(totalPrice); order.setUserId(userId); order.setStatus(0); // 待处理 orderMapper.insert(order); // 3. 批量插入订单项、删除购物车项 for (Cart cart : cartList) { Goods goods goodsMapper.selectById(cart.getGoodsId()); // 库存校验 if (goods.getStock() cart.getQuantity()) { throw new BusinessException(商品 goods.getName() 库存不足); } OrderItem item new OrderItem(); item.setOrderId(order.getId()); item.setGoodsId(goods.getId()); item.setGoodsName(goods.getName()); item.setGoodsImage(goods.getMainImage()); item.setPrice(goods.getPrice()); item.setQuantity(cart.getQuantity()); orderItemMapper.insert(item); // 扣库存、加销量 goodsMapper.decreaseStock(goods.getId(), cart.getQuantity()); goodsMapper.increaseSales(goods.getId(), cart.getQuantity()); } cartMapper.deleteByIds(cartIds); return order; }注意 Transactional 注解一定要加 rollbackFor Exception.class。Spring 默认只在遇到 RuntimeException 时回滚如果业务层抛出的是 Exception不加这个参数事务不会回滚这是个极其经典的坑。订单号生成逻辑看起来简单但已经足够满足这个项目的需求。更严格的场景要用雪花算法或者 Redis 自增但小饰品城这个真实业务量根本用不上。4. 前端 Vue 核心页面实现4.1 工程初始化和路由设计Vue 端我用 Vue CLI 创建工程选上 Router、Vuex或 Pinia、Axios 这几个标配。路由设计直接决定了页面结构我习惯把路由分成两块const routes [ // 前台用户端 { path: /, name: Home, component: Home }, { path: /goods, name: GoodsList, component: GoodsList }, { path: /goods/:id, name: GoodsDetail, component: GoodsDetail }, { path: /cart, name: Cart, component: Cart, meta: { requiresAuth: true } }, { path: /order, name: OrderList, component: OrderList, meta: { requiresAuth: true } }, // 后台管理端 { path: /admin/login, name: AdminLogin, component: AdminLogin }, { path: /admin, name: AdminLayout, component: AdminLayout, redirect: /admin/dashboard, children: [ { path: dashboard, component: AdminDashboard }, { path: goods, component: AdminGoods }, { path: order, component: AdminOrder }, ] } ]meta.requiresAuth 字段配合全局前置守卫做登录拦截——用户没登录就点进购物车或订单页直接跳转到登录页。这个交互非常常见实现起来也很简单router.beforeEach((to, from, next) { if (to.meta.requiresAuth !localStorage.getItem(token)) { next({ path: /login }); } else { next(); } });4.2 Axios 封装与统一拦截商城页面的数据分析几十个接口都要处理 loading 状态、错误提示、token 传递如果不做统一封装前端代码里会到处散落重复的马蹄逻辑。import axios from axios; const request axios.create({ baseURL: /api, timeout: 10000 }); // 请求拦截器附加上 token request.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] token; } return config; }); // 响应拦截器统一处理后端返回结构 request.interceptors.response.use(response { const res response.data; if (res.code 200) { return res.data; } // 未登录或登录过期 if (res.code 401) { localStorage.removeItem(token); window.location.href /login; } ElMessage.error(res.message); return Promise.reject(new Error(res.message)); }, error { ElMessage.error(网络请求异常); return Promise.reject(error); }); export default request;这样封装之后每个业务接口只需要关心成功之后拿到的 data 数据错误提示和登录跳转全部统一处理开发效率提升非常明显。4.3 首页与商品列表页首页最重要的部分是轮播图、分类导航和热门商品。轮播图数据从 banner 表读取热门商品取 sales 最高的几个商品渲染。分类导航区域展示一级分类点击后跳转到商品列表页并带上分类 id。商品列表页是前台最核心的页面布局和操作直接影响用户的购物体验。我的列表页布局是左sidebar分类树、右侧商品网格顶部有搜索框。筛选条件联动采用“变化即请求”的方式用户切换分类或者输入关键词后触发接口请求这样代码简单、交互反馈及时。每个商品卡片上展示主图、名称、价格和销量鼠标移入时出现“加入购物车”按钮点击直接调购物车接口不需要跳页面。4.4 购物车与订单结算页购物车页面的核心交互是数量加减和选中勾选。我选了 Vuex 管理购物车状态每次加购、改数量、勾选都同步更新 store这样在购物车和结算页之间跳转时数据是共享的不需要反复请求接口。提交订单时要向后端传递的是购物车项的 id 数组和收货地址信息。前端把选中的项收集起来调取接口后跳转到订单列表页告诉用户“订单提交成功”。支付环节在这个项目里做了简化处理后续如果要扩展可以在订单状态机里增加“待支付”和“已支付”状态接口层面配合支付回调就够了。4.5 后台管理页面后台管理页是另一个独立布局左侧菜单右侧内容区。商品管理用 el-table 展示每行提供编辑和删除操作新增/编辑用 el-dialog 弹窗表单图片上传用 el-upload 组件调后端的文件上传接口。订单管理按状态筛选提供“确认订单”和“完成订单”的操作按钮。仪表盘用简单的卡片统计展示商品总数、订单总数、用户总数用条形图展示最近几天的订单量趋势。后台和前台的差异在于后台交互表单多、数据操作密集、权限要求高。Vue 的响应式数据和组件化在这个场景非常顺手比用 JSP 那种传统方式开发要高效太多了。5. 环境配置、联调与部署5.1 本地开发环境后端这边需要 JDK 1.8、Maven 3.6、MySQL 5.7。SSM 项目建议用 IDEA 开发前端用 Vue CLI 创建后跑在 8080 端口后端 Spring Boot 跑在 8081生产环境用 Nginx 做反向代理和静态资源服务。要注意的是本地联调时的跨域问题。解决方案有两个要么在后端配置 CORS 允许前端地址访问Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(http://localhost:8080) .allowedMethods(GET, POST, PUT, DELETE); } }要么在前端 vue.config.js 里配置 devServer 的 proxy 代理把 /api 前缀的请求代理到后端地址。个人更推荐代理方式因为生产环境几乎总是统一域名的方案代理方式能保持前后端代码里都只写相对路径部署时不用改代码。5.2 打包与部署部署是国内环境最常用的组合Nginx 跑前端静态文件和反向代理Tomcat 或内置容器跑后端接口。具体步骤后端打包mvn clean package 生成 war 或者 jar扔到服务器上运行前端打包npm run build 生成 dist 目录把 dist 里的静态文件拷贝到 Nginx html 目录Nginx 配置反向代理统一入口server { listen 80; server_name localhost; location / { root /usr/share/nginx/html/dist; index index.html; try_files $uri $uri/ /index.html; # 解决 Vue Router 刷新404问题 } location /api/ { proxy_pass http://127.0.0.1:8081/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files 那行一定要写否则 Vue 的 history 模式路由在页面刷新时会报 404。这是前后端分离部署最经典的坑我见过很多次了。5.3 数据库初始化数据库初始化我用了一个统一的 SQL 脚本包含建库语句和表结构。上线前再把配置文件的数据库地址、账号密码改成生产环境的值。注意密码不要写在配置里提交到公开仓库至少要用环境变量或配置文件外置的方式管理敏感信息这个习惯要从小项目开始养成。6. 常见问题排查与踩坑实录6.1 前端请求接口报 404这个问题的根源通常是两个Nginx 代理没配置好或者后端接口路径和前端请求路径不一致。排查思路是先用浏览器开发者工具的 Network 面板看请求 URL 是不是符合预期再到后端的控制器里核对 RequestMapping 的路径。有时候最后一个斜杠的差异都会导致匹配失败尤其在 Spring 的精确匹配模式下。6.2 图片上传成功但页面上不显示图片上传后返回的通常是相对路径比如 /upload/xxx.jpg。前端要把这个路径拼上完整的图片地址前缀才能访问。这个问题常出现在本地联调时因为前后端端口不同相对路径会解析到前端的地址结果找不到图片。解决办法绕不开两种后端把图片地址的完整访问路径返回给前端或者前端在请求头设置代理让图片请求也走后端转发。6.3 购物车加入失败前端没提示最常见的原因是后端报错被全局异常处理拦截后返回了500但前端的响应拦截器没有把错误信息展示到页面上。我的建议是在响应拦截器里对 code 非200的情况统一展示错误消息既不遗漏异常也不让用户对着空白页发呆。6.4 订单用户统计不准确曾碰到过仪表盘的订单数统计和订单列表总数对不上的情况最后发现是统计 SQL 的筛选条件和列表 SQL 不一致。这类问题往往是统计时用了 status 过滤列表查询没有两边口径不同。这个问题提醒我的经验是每个统计数字必须写清楚统计口径并做一次跨接口的数据核对。6.5 常见问题速查表问题现象可能原因解决方法登录接口报跨域错误前后端端口不同CORS未配置配置CORS或使用前端代理列表页刷新就404Nginx未配置try_files增加try_files $uri $uri/ /index.html分页页码一直相同offset计算错误核对pageNum和pageSize的计算逻辑订单列表查不到刚下的订单事务未提交检查Transactional配置排查代码逻辑图片上传成功但回显失败图片地址路径拼接错误检查返回路径与静态资源映射后台修改商品后列表没更新前端缓存确认请求响应是否正常必要时清缓存6.6 最后一个建议坦白说这类项目最难的部分从来不是某个单独的技术点而是把所有模块像拼图一样组合成一个可运行的完整系统。做的时候不要闷头写代码先把接口清单和表结构理清楚然后按模块逐个打通每完成一个模块就前后端联调一次。这样每个阶段的工作量是可控的问题也能在第一时间暴露并解决。如果你是在校生拿这个项目练手我更建议把重点放在理解订单和购物车这类核心链路的数据流转上。SSM 和 Vue 都是手段真正值钱的是你在完成项目的过程中形成的全局观——知道一个请求从前端页面点击到数据库返回数据的完整旅程知道一个订单从创建到完成在系统里留下了哪些痕迹。有了这套认知后续学什么新框架都不会慌。
1. 项目概述与需求拆解1.1 这是个什么项目看到这个标题我猜不少人第一反应是这就是个典型的毕业设计选题。确实SSM Vue的组合在近年来已经成了高校软件工程类项目的事实标配但真正把它做好、做完整并不是把框架搭起来跑个Hello World那么简单。这个项目是面向青岛市城阳小饰品城开发的电商类网站。业务背景理解起来很直接小饰品城是一个线下批发与零售并存的商圈有大量商户和商品需要一个线上展示与交易窗口。系统要覆盖两类用户——普通消费者在网站上看商品、搜商品、加购物车、下订单后台管理人员维护商品信息、处理订单、管理分类、发布公告。这种模式行业内叫 B2C 轻电商跟全品类的京东、天猫比它的业务深度要浅一些但该有的核心链路一条不少。1.2 解决的核心问题是什么这类网站要解决的实际问题可以归纳成三个层面第一信息展示的线上化。小饰品城线下档口多、商品更新快消费者靠逛很难准确找到店铺和商品网站需要提供分类浏览和关键词检索能力让“找货”这件事变高效。第二交易流程的线上化。用户选完商品后要在网上下单订单进入后台管理员审核处理用户能查看订单状态。整个流程从线下口头的买卖变成系统留痕的交易闭环。第三运营管理的集中化。后台不是简单的商品发布工具还涉及库存管理、分类调整、轮播图维护、公告通知、用户管理等一系列运营动作。1.3 技术选型的现实考量SSM 指的是 Spring SpringMVC MyBatis 三件套。这套技术在 Java 服务端领域虽然有了更年轻的替代品但它依然是无数项目的基石而且学习资料、问题排查经验极其丰富对于需要一个完整项目经验的人来说非常合适。前端选 Vue是因为它组件化开发、数据驱动视图的特点非常适合商城这类交互密集型的页面。商品列表、商品详情、购物车、结算页这些功能如果用传统模板引擎做往往是后端拼字符串前端调样式开发和维护都累。用 Vue 做前后端分离后端只提供 JSON 数据接口前端负责渲染和交互分工明确。提示不要把“SSM 过时了”当成不选它的理由。一个项目的价值不在框架新旧在于业务链路是否完整、代码结构是否清晰。面试官关心的往往是你是否真的理解这套架构而不是你用了多新的框架。2. 业务模块划分与数据库设计2.1 功能模块全景做项目第一步千万别急着写代码先把模块边界画清楚。我通常会用一个简单的功能清单来约束需求范围前台用户端注册登录、商品分类浏览、商品搜索、商品详情、购物车、订单提交、个人中心订单列表、地址管理后台管理端管理员登录、商品分类管理、商品管理、订单管理、用户管理、公告管理、轮播图管理这套功能对应了一个电商系统的最小完备集。购物车和订单是交易主干分类和搜索是商品检索主干后台管理则承接运营侧的日常操作。没有加入支付、物流跟踪这类复杂度很高的子系统这是正确的取舍——项目体量要匹配实际周期和精力。2.2 核心表结构设计数据库设计是这类项目的定盘星表结构一旦定错后面写代码会非常痛苦。我自己习惯把核心表设计成下面这样表名用途关键字段user用户表id, username, password, nickname, phone, avatar, create_timecategory商品分类表id, name, parent_id, sort_ordergoods商品表id, category_id, name, subtitle, main_image, price, stock, sales, detailcart购物车表id, user_id, goods_id, quantity, checked, create_timeorder订单表id, order_no, user_id, total_price, status, receiver_name, receiver_phone, receiver_address, create_timeorder_item订单项表id, order_id, goods_id, goods_name, goods_image, price, quantityannouncement公告表id, title, content, publish_timebanner轮播图表id, image_url, link_url, sort_orderadmin管理员表id, username, password2.3 表设计中的关键决策点有几个设计决策值得展开讲讲。商品表里的分类字段为什么只存 category_id不冗余分类名称因为通过关联查询可以拿到分类名冗余反而会造成数据不一致。但 order_item 表里我刻意冗余了 goods_name 和 goods_image原因也很简单订单生成后商品信息可能被管理员修改甚至删除订单表里如果只存 goods_id用户查看历史订单时就会拿到已经变化的数据甚至查不到商品。订单需要的是交易发生那一刻的快照这是电商系统的通用设计惯例。订单表的状态字段我推荐用数字枚举而不是字符串。比如 0 表示待处理、1 表示已确认、2 表示已完成、3 表示已取消。数字存储占用小、查询排序方便配合 Java 端的枚举类做映射代码可读性也不差。商品表里专门留了 sales 销量字段这个字段别看简单它支撑了前台“销量排序”的查询逻辑也在商品列表页实现了一个小的“热销推荐”模块。顺序是后台管理员每处理完一个订单就把订单里的商品销量累加到 goods.sales 上保证销量数据的近似实时。2.4 SQL 初始化与造数据表结构设计完之后一定要写一套完整的初始化 SQL包含建库、建表、基础数据三部分。基础数据至少要包括若干测试用户、一条管理员账号、五个左右的分类项链、手链、耳饰、发饰、戒指等、每个分类下十条以上商品、一两条公告和轮播图。很多人在这个环节偷懒只建表不造数据等写完了前后端联调的时候才发现页面空空如也视觉效果和功能验证都很受影响。我给的建议是造数据的动作跟设计表结构同步完成商品图片可以先从图床或者本地静态资源里找一批示例图不用过度纠结图片完美度但数量一定要够——一套合理的演示数据对整个开发过程的帮助非常明显。3. 后端 SSM 框架核心技术实现3.1 项目结构与分层规范后端工程建议用 Maven 做标准的多模块单工程结构虽然项目规模不算大不需要真正拆多个 Maven Module但包结构一定要清晰。我推荐的包划分com.zhenpin.smallmarket ├── controller // 控制层接收请求、返回JSON ├── service // 业务层接口 │ └── impl // 业务层实现 ├── dao // MyBatis的Mapper接口 ├── entity // 实体类 ├── vo // 视图对象对接前端展示 ├── common // 通用类统一返回结果、异常处理、工具类 └── config // 配置类拦截器、跨域等分层的好处在于每个请求的路径是固定的Controller 接参数 - Service 做业务处理 - Dao 访问数据库。出了问题能快速定位在第几层而不是在一堆类里大海捞针。3.2 统一返回结果与全局异常处理这是很多项目容易忽略但必须有的设计。我见过不少项目Controller 返回值一会儿是 String一会儿是 Map一会儿直接返回实体类前端拿到数据还得猜格式。这非常影响联调效率。建议定义一个统一的 Result 类包含 code、message 和 data 三个字段所有接口的返回结构都是一样的public class ResultT { private Integer code; // 200表示成功500表示失败 private String message; // 提示信息 private T data; // 业务数据 public static T ResultT success(T data) { ResultT result new Result(); result.setCode(200); result.setMessage(操作成功); result.setData(data); return result; } public static T ResultT fail(String message) { ResultT result new Result(); result.setCode(500); result.setMessage(message); return result; } }配合 ControllerAdvice 做全局异常处理把业务异常和未知异常统一拦截Controller 里就不用到处写 try-catch 了代码会干净很多。这个习惯在任何 Java Web 项目里都值得保持。3.3 核心业务接口清单前端需要的后端接口我按业务模块整理了一份清单开发的时候照着这个表逐项补全不容易遗漏模块接口路径功能说明用户POST /api/user/register用户注册用户POST /api/user/login用户登录用户GET /api/user/info获取当前用户信息商品GET /api/goods/list商品分页列表支持分类、关键词过滤商品GET /api/goods/detail/{id}商品详情购物车GET /api/cart/list查询购物车购物车POST /api/cart/add加入购物车购物车POST /api/cart/update修改数量购物车POST /api/cart/delete删除购物车项支持批量订单POST /api/order/create提交订单订单GET /api/order/list当前用户的订单列表订单POST /api/order/updateStatus更新订单状态后台用管理POST /api/admin/login管理员登录管理GET /api/admin/goods/list后台商品管理列表管理POST /api/admin/goods/save新增/修改商品管理DELETE /api/admin/goods/{id}删除商品管理GET /api/admin/order/list后台订单列表管理GET /api/admin/stats仪表盘统计数据接口路径规范很重要前后端分离项目最怕的就是接口约定不清晰。路径里用复数名词表示资源HTTP 方法表示动作这虽然是 REST 风格的皮毛但比乱写接口要规范太多。3.4 MyBatis 的 SQL 编写要点MyBatis 是这个框架组合里最需要基本功的一环。很多同学的 SQL 写得很粗糙只会在单表上做简单的 select、insert、update。但商城项目里的业务查询多表关联和动态 SQL 是很常见的需求。商品列表的分页查询就是一个典型场景。前端传过来 categoryId、keyword、pageNum、pageSize 四个参数对应的 Mapper 写法是这样的select idselectGoodsPage resultTypecom.zhenpin.smallmarket.vo.GoodsVO SELECT g.id, g.name, g.subtitle, g.main_image, g.price, g.sales, c.name AS category_name FROM goods g LEFT JOIN category c ON g.category_id c.id where if testcategoryId ! null AND g.category_id #{categoryId} /if if testkeyword ! null and keyword ! AND g.name LIKE CONCAT(%, #{keyword}, %) /if /where ORDER BY g.sales DESC LIMIT #{offset}, #{limit} /select动态 SQL 的 where 标签帮我们解决了条件拼接时多余的 AND 和 WHERE 问题这是 MyBatis 的经典用法。LEFT JOIN 关联分类表是为了在前端商品列表上直接展示分类名称避免前端再发起第二次请求。分页这里我特意用的 LIMIT #{offset}, #{limit}因为简单直观、易于控制。也可以用 PageHelper 这类分页插件但我不建议在这个项目里引入——手写分页能让你真正理解分页的原理而且代码量并不大面试的时候还能把底层逻辑讲清楚。3.5 下单流程的事务控制订单创建是整个后端最需要严谨对待的业务逻辑因为涉及多张表的写操作生成订单、生成订单项、清空购物车、扣减库存、累加销量。任何一个步骤失败都会造成数据不一致所以事务控制是刚需。核心逻辑大致如下Override Transactional(rollbackFor Exception.class) public Order createOrder(Long userId, Long addressId, ListLong cartIds) { // 1. 查询购物车选中的商品项 ListCart cartList cartMapper.selectByIds(userId, cartIds); if (cartList null || cartList.isEmpty()) { throw new BusinessException(购物车中没有选中的商品); } // 2. 计算总价并生成订单 Order order new Order(); // 生成订单号时间戳 用户id后四位 随机数 String orderNo String.valueOf(System.currentTimeMillis()) String.format(%04d, userId) String.valueOf((int)(Math.random() * 900) 100); order.setOrderNo(orderNo); BigDecimal totalPrice BigDecimal.ZERO; for (Cart cart : cartList) { Goods goods goodsMapper.selectById(cart.getGoodsId()); totalPrice totalPrice.add(goods.getPrice().multiply( BigDecimal.valueOf(cart.getQuantity()))); } order.setTotalPrice(totalPrice); order.setUserId(userId); order.setStatus(0); // 待处理 orderMapper.insert(order); // 3. 批量插入订单项、删除购物车项 for (Cart cart : cartList) { Goods goods goodsMapper.selectById(cart.getGoodsId()); // 库存校验 if (goods.getStock() cart.getQuantity()) { throw new BusinessException(商品 goods.getName() 库存不足); } OrderItem item new OrderItem(); item.setOrderId(order.getId()); item.setGoodsId(goods.getId()); item.setGoodsName(goods.getName()); item.setGoodsImage(goods.getMainImage()); item.setPrice(goods.getPrice()); item.setQuantity(cart.getQuantity()); orderItemMapper.insert(item); // 扣库存、加销量 goodsMapper.decreaseStock(goods.getId(), cart.getQuantity()); goodsMapper.increaseSales(goods.getId(), cart.getQuantity()); } cartMapper.deleteByIds(cartIds); return order; }注意 Transactional 注解一定要加 rollbackFor Exception.class。Spring 默认只在遇到 RuntimeException 时回滚如果业务层抛出的是 Exception不加这个参数事务不会回滚这是个极其经典的坑。订单号生成逻辑看起来简单但已经足够满足这个项目的需求。更严格的场景要用雪花算法或者 Redis 自增但小饰品城这个真实业务量根本用不上。4. 前端 Vue 核心页面实现4.1 工程初始化和路由设计Vue 端我用 Vue CLI 创建工程选上 Router、Vuex或 Pinia、Axios 这几个标配。路由设计直接决定了页面结构我习惯把路由分成两块const routes [ // 前台用户端 { path: /, name: Home, component: Home }, { path: /goods, name: GoodsList, component: GoodsList }, { path: /goods/:id, name: GoodsDetail, component: GoodsDetail }, { path: /cart, name: Cart, component: Cart, meta: { requiresAuth: true } }, { path: /order, name: OrderList, component: OrderList, meta: { requiresAuth: true } }, // 后台管理端 { path: /admin/login, name: AdminLogin, component: AdminLogin }, { path: /admin, name: AdminLayout, component: AdminLayout, redirect: /admin/dashboard, children: [ { path: dashboard, component: AdminDashboard }, { path: goods, component: AdminGoods }, { path: order, component: AdminOrder }, ] } ]meta.requiresAuth 字段配合全局前置守卫做登录拦截——用户没登录就点进购物车或订单页直接跳转到登录页。这个交互非常常见实现起来也很简单router.beforeEach((to, from, next) { if (to.meta.requiresAuth !localStorage.getItem(token)) { next({ path: /login }); } else { next(); } });4.2 Axios 封装与统一拦截商城页面的数据分析几十个接口都要处理 loading 状态、错误提示、token 传递如果不做统一封装前端代码里会到处散落重复的马蹄逻辑。import axios from axios; const request axios.create({ baseURL: /api, timeout: 10000 }); // 请求拦截器附加上 token request.interceptors.request.use(config { const token localStorage.getItem(token); if (token) { config.headers[Authorization] token; } return config; }); // 响应拦截器统一处理后端返回结构 request.interceptors.response.use(response { const res response.data; if (res.code 200) { return res.data; } // 未登录或登录过期 if (res.code 401) { localStorage.removeItem(token); window.location.href /login; } ElMessage.error(res.message); return Promise.reject(new Error(res.message)); }, error { ElMessage.error(网络请求异常); return Promise.reject(error); }); export default request;这样封装之后每个业务接口只需要关心成功之后拿到的 data 数据错误提示和登录跳转全部统一处理开发效率提升非常明显。4.3 首页与商品列表页首页最重要的部分是轮播图、分类导航和热门商品。轮播图数据从 banner 表读取热门商品取 sales 最高的几个商品渲染。分类导航区域展示一级分类点击后跳转到商品列表页并带上分类 id。商品列表页是前台最核心的页面布局和操作直接影响用户的购物体验。我的列表页布局是左sidebar分类树、右侧商品网格顶部有搜索框。筛选条件联动采用“变化即请求”的方式用户切换分类或者输入关键词后触发接口请求这样代码简单、交互反馈及时。每个商品卡片上展示主图、名称、价格和销量鼠标移入时出现“加入购物车”按钮点击直接调购物车接口不需要跳页面。4.4 购物车与订单结算页购物车页面的核心交互是数量加减和选中勾选。我选了 Vuex 管理购物车状态每次加购、改数量、勾选都同步更新 store这样在购物车和结算页之间跳转时数据是共享的不需要反复请求接口。提交订单时要向后端传递的是购物车项的 id 数组和收货地址信息。前端把选中的项收集起来调取接口后跳转到订单列表页告诉用户“订单提交成功”。支付环节在这个项目里做了简化处理后续如果要扩展可以在订单状态机里增加“待支付”和“已支付”状态接口层面配合支付回调就够了。4.5 后台管理页面后台管理页是另一个独立布局左侧菜单右侧内容区。商品管理用 el-table 展示每行提供编辑和删除操作新增/编辑用 el-dialog 弹窗表单图片上传用 el-upload 组件调后端的文件上传接口。订单管理按状态筛选提供“确认订单”和“完成订单”的操作按钮。仪表盘用简单的卡片统计展示商品总数、订单总数、用户总数用条形图展示最近几天的订单量趋势。后台和前台的差异在于后台交互表单多、数据操作密集、权限要求高。Vue 的响应式数据和组件化在这个场景非常顺手比用 JSP 那种传统方式开发要高效太多了。5. 环境配置、联调与部署5.1 本地开发环境后端这边需要 JDK 1.8、Maven 3.6、MySQL 5.7。SSM 项目建议用 IDEA 开发前端用 Vue CLI 创建后跑在 8080 端口后端 Spring Boot 跑在 8081生产环境用 Nginx 做反向代理和静态资源服务。要注意的是本地联调时的跨域问题。解决方案有两个要么在后端配置 CORS 允许前端地址访问Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOrigins(http://localhost:8080) .allowedMethods(GET, POST, PUT, DELETE); } }要么在前端 vue.config.js 里配置 devServer 的 proxy 代理把 /api 前缀的请求代理到后端地址。个人更推荐代理方式因为生产环境几乎总是统一域名的方案代理方式能保持前后端代码里都只写相对路径部署时不用改代码。5.2 打包与部署部署是国内环境最常用的组合Nginx 跑前端静态文件和反向代理Tomcat 或内置容器跑后端接口。具体步骤后端打包mvn clean package 生成 war 或者 jar扔到服务器上运行前端打包npm run build 生成 dist 目录把 dist 里的静态文件拷贝到 Nginx html 目录Nginx 配置反向代理统一入口server { listen 80; server_name localhost; location / { root /usr/share/nginx/html/dist; index index.html; try_files $uri $uri/ /index.html; # 解决 Vue Router 刷新404问题 } location /api/ { proxy_pass http://127.0.0.1:8081/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }try_files 那行一定要写否则 Vue 的 history 模式路由在页面刷新时会报 404。这是前后端分离部署最经典的坑我见过很多次了。5.3 数据库初始化数据库初始化我用了一个统一的 SQL 脚本包含建库语句和表结构。上线前再把配置文件的数据库地址、账号密码改成生产环境的值。注意密码不要写在配置里提交到公开仓库至少要用环境变量或配置文件外置的方式管理敏感信息这个习惯要从小项目开始养成。6. 常见问题排查与踩坑实录6.1 前端请求接口报 404这个问题的根源通常是两个Nginx 代理没配置好或者后端接口路径和前端请求路径不一致。排查思路是先用浏览器开发者工具的 Network 面板看请求 URL 是不是符合预期再到后端的控制器里核对 RequestMapping 的路径。有时候最后一个斜杠的差异都会导致匹配失败尤其在 Spring 的精确匹配模式下。6.2 图片上传成功但页面上不显示图片上传后返回的通常是相对路径比如 /upload/xxx.jpg。前端要把这个路径拼上完整的图片地址前缀才能访问。这个问题常出现在本地联调时因为前后端端口不同相对路径会解析到前端的地址结果找不到图片。解决办法绕不开两种后端把图片地址的完整访问路径返回给前端或者前端在请求头设置代理让图片请求也走后端转发。6.3 购物车加入失败前端没提示最常见的原因是后端报错被全局异常处理拦截后返回了500但前端的响应拦截器没有把错误信息展示到页面上。我的建议是在响应拦截器里对 code 非200的情况统一展示错误消息既不遗漏异常也不让用户对着空白页发呆。6.4 订单用户统计不准确曾碰到过仪表盘的订单数统计和订单列表总数对不上的情况最后发现是统计 SQL 的筛选条件和列表 SQL 不一致。这类问题往往是统计时用了 status 过滤列表查询没有两边口径不同。这个问题提醒我的经验是每个统计数字必须写清楚统计口径并做一次跨接口的数据核对。6.5 常见问题速查表问题现象可能原因解决方法登录接口报跨域错误前后端端口不同CORS未配置配置CORS或使用前端代理列表页刷新就404Nginx未配置try_files增加try_files $uri $uri/ /index.html分页页码一直相同offset计算错误核对pageNum和pageSize的计算逻辑订单列表查不到刚下的订单事务未提交检查Transactional配置排查代码逻辑图片上传成功但回显失败图片地址路径拼接错误检查返回路径与静态资源映射后台修改商品后列表没更新前端缓存确认请求响应是否正常必要时清缓存6.6 最后一个建议坦白说这类项目最难的部分从来不是某个单独的技术点而是把所有模块像拼图一样组合成一个可运行的完整系统。做的时候不要闷头写代码先把接口清单和表结构理清楚然后按模块逐个打通每完成一个模块就前后端联调一次。这样每个阶段的工作量是可控的问题也能在第一时间暴露并解决。如果你是在校生拿这个项目练手我更建议把重点放在理解订单和购物车这类核心链路的数据流转上。SSM 和 Vue 都是手段真正值钱的是你在完成项目的过程中形成的全局观——知道一个请求从前端页面点击到数据库返回数据的完整旅程知道一个订单从创建到完成在系统里留下了哪些痕迹。有了这套认知后续学什么新框架都不会慌。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
