简介基于SSMVue的汉服文化平台网站是一套可直接用于毕业设计的完整Java项目面向计算机相关专业正在做毕设的学生及需要项目实战练习的Java学习者也可作为课程设计或期末大作业。项目经严格调试确保可正常运行。压缩包共867个文件约21.74MB包含Java源码、Vue组件、JavaScript脚本、HTML页面、数据库SQL脚本及开发文档等类型覆盖前端、后端、配置与文档结构清晰。内容涵盖管理员、用户及前台首页三大模块实现汉服知识管理、服装展示、用户相册、论坛交流、购物车、订单管理等完整功能。另有演示视频、部署视频、代码讲解视频及全套开发软件并附有环境说明JDK1.8、Tomcat7、MySQL5.7方便快速启动项目。已有138人学习适合需要完整可运行毕设方案和实战练习的读者。1. 从「毕设选题」到「可上线的小型电商站」SSM Vue 的汉服平台到底能做到什么程度一个汉服文化平台网站表面上是商品展示加下单实际上一旦开始动手你会碰到的是一整套 Web 工程问题用户注册登录、商品分类与检索、购物车与订单状态机、后台管理、图片上传与回显、前后端联调与跨域、部署上线。市面上很多脚手架要么只有 Spring Boot 单体要么只有 Vue 管理端真正把 SSMSpring SpringMVC MyBatis和 Vue 组合起来、又能跑通完整业务闭环的参考项目其实不多。这篇文章用一套「基于 SSM Vue 的汉服文化平台」的典型设计把从建表到联调再到部署的关键步骤拆开讲重点放在那些新手会卡住、熟手也容易忽略的边界细节上。适合正在做 Java Web 毕设的在校生也适合刚接手 SSR 老项目、想快速理解前后端分离架构的初级工程师——你可以照着这套思路复现一个最小可用版本再按自己的业务去扩展。2. 为什么用 SSM Vue而不是 Spring Boot 模板引擎选型逻辑与整体架构2.1 SSM 三件套各自管什么Spring、SpringMVC、MyBatis 的分工边界先明确一个容易被考到也容易被搞混的点SSM 不是一个框架而是三个框架的组合。Spring 负责对象管理和依赖注入SpringMVC 负责 HTTP 请求到方法的映射MyBatis 负责 SQL 与 Java 对象之间的转换。一句话总结Spring 管装配SpringMVC 管路由MyBatis 管数据。汉服平台的典型场景是前端 Vue 发一个POST /api/user/login请求Tomcat 收到后交给 DispatcherServletDispatcherServlet 通过 HandlerMapping 找到 LoginController 里的对应方法方法里调用 UserServiceUserService 再通过 UserMapper 接口找到 MyBatis 生成的代理对象最终执行 XML 里写好的 SQL把结果逐层返回。这一套链路里任何一个环节的配置断了前端只会看到 404 或 500而不会告诉你到底是哪一层出了问题——这也是很多新手第一次联调时最沮丧的地方。我在实际排查这类项目时首先会确认web.xml里的 DispatcherServlet 配置和spring-mvc.xml的组件扫描路径是否一致。比如 controller 包是com.hanfu.controller但扫描路径写成了com.hanfu.service那所有接口都会直接 404而且后端日志没有任何异常。这种问题不是代码逻辑错误而是配置漂移。2.2 Vue 2 还是 Vue 3给一个不纠结的答案很多拿到这类项目的人会问Vue 2 还是 Vue 3答案取决于你的参考项目本身。如果项目里用的是 Vue 2 Element UI vue-router 3 Vuex 3你在没有充分理由的情况下升级到 Vue 3 是给自己挖坑——Vue 3 的 Composition API、Element Plus、vue-router 4 在生态上已经有很大变化升级过程中你会花大量时间处理「看着差不多但就是不工作」的细节。但如果你是从零开始搭我建议 Vue 3 Vite Pinia。原因很实际Vue 2 已经停止维护新装的依赖经常和 Node 版本冲突Vue 3 的setup语法让组件逻辑更集中对一个商品列表加购物车的页面来说代码量反而更少。不过要注意如果你在 IDEA 里打开的是一个 Vue 2 老项目npm install时报错别急着升级版本先看 Node 版本是不是太高了Vue 2 项目配合 Node 16 通常比 Node 18 更省心。2.3 分层架构为什么 controller 不能直接写 SQL汉服平台这种规模的业务最忌讳的就是 controller 里揉进业务逻辑和 SQL。我会严格按照 controller → service → mapper → entity 四层来组织后端代码。controller 只接收参数、调用 service、返回统一结果service 写业务规则比如下单时检查库存、计算总价mapper 只写 SQL 和参数映射entity 对应数据库表结构。这样做的好处在排错时特别明显。比如订单金额算错了如果你把价格计算写在 controller 里那前端传什么参数就按什么算没有任何防御如果写在 service 里你就可以在 service 层加日志、加单元测试不用动 controller 和 SQL 就能定位问题。另一个好处是复用——后台管理端和前台商城可能都需要查订单列表两个 controller 共用一个 service 方法参数不同而已。依赖方向必须单向controller 依赖 serviceservice 依赖 mapper谁都不能反向。如果你发现某个 mapper 方法里又调了 service说明设计已经乱了趁早重构。3. 从数据库设计到第一个能跑的登录接口核心表与 MyBatis 实战3.1 汉服平台的表结构设计用户、商品、订单、收藏四张表就够了一套能支撑「静态展示 购物下单 后台管理」的汉服平台最少需要这几张表用户表user、汉服商品表costume、订单表order、订单明细表order_item、收藏表favorite再加一个分类表category。不要一开始就设计十几张表业务没到那一步表越多联调越痛苦。用户表的设计有个容易踩的坑密码字段。明文存储是绝对不能接受的我用的是 BCrypt 加密Spring Security 里自带BCryptPasswordEncoder不引 Security 的话可以用 jBCrypt 的独立库。加密的意义在于数据库泄露时攻击者拿到的是一串随机散列而不是用户的原始密码。对于毕设项目这是评委一定会问的点。商品表需要注意的字段是「上下架状态」和「库存」。状态字段用TINYINT0 表示下架、1 表示上架比用字符串有效率得多。库存字段不能只是展示用下单时要扣减所以它必须参与事务。CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT, username VARCHAR(50) NOT NULL, password VARCHAR(100) NOT NULL, nickname VARCHAR(50) DEFAULT NULL, avatar VARCHAR(255) DEFAULT NULL, role TINYINT DEFAULT 0 COMMENT 0-普通用户 1-管理员, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE costume ( id INT NOT NULL AUTO_INCREMENT, category_id INT DEFAULT NULL, name VARCHAR(100) NOT NULL, description TEXT, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, image VARCHAR(255) DEFAULT NULL, status TINYINT DEFAULT 1 COMMENT 0-下架 1-上架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这两张表的细节提醒所有字符串字段用utf8mb4而不是utf8否则用户填的生僻字或 Emoji 表情会报Incorrect string value错误。密码字段长度预留 100 是因为 BCrypt 加密后的字符串长度是 60但保险起见给足余量。UNIQUE KEY加在用户名上是必须的否则注册接口会重复插入数据。3.2 用 MyBatis 写动态 SQL商品列表和条件筛选商城的商品列表页不可能只有一个SELECT * FROM costume用户会按分类筛选、按价格排序、搜关键字。这些条件组合在 MyBatis 里用where标签加if判断来实现避免手动拼接 SQL 时漏掉WHERE关键字或者多出一个AND。select idlistByCondition resultTypecom.hanfu.entity.Costume SELECT id, category_id, name, description, price, stock, image, status FROM costume where if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND name LIKE CONCAT(%, #{keyword}, %) /if if teststatus ! null AND status #{status} /if /where if testorderBy ! null and orderBy ! ORDER BY ${orderBy} /if LIMIT #{offset}, #{pageSize} /select这里有两个关键点。第一#{}和${}的区别#{}是预编译参数占位符MyBatis 会生成?能防 SQL 注入${}是字符串拼接直接把值拼进 SQL永远不要用${}接收前端传的值。上面代码里ORDER BY ${orderBy}是有意为之因为排序字段不能参数化但必须在 service 层做白名单校验只允许传入price ASC、price DESC、create_time DESC这几个固定值。第二CONCAT(%, #{keyword}, %)不要写成%${keyword}%后者有注入风险。模糊搜索在数据量小的时候用 LIKE 没问题数据量过百万再考虑全文索引或 Elasticsearch现阶段不用过度设计。3.3 登录接口的前后实现与 Postman 验证登录是第一个联调接口跑通了它后面所有接口的套路都是一样的。后端用一个LoginController接收参数service 里校验用户名密码成功则返回用户信息和一个 token。RestController RequestMapping(/api/user) public class LoginController { Resource private UserService userService; PostMapping(/login) public Result login(RequestBody LoginDTO dto) { if (dto.getUsername() null || dto.getPassword() null) { return Result.error(用户名和密码不能为空); } User user userService.login(dto.getUsername(), dto.getPassword()); if (user null) { return Result.error(用户名或密码错误); } // 登录成功生成 token实际项目用 JWT 或 Redis 会话 String token UUID.randomUUID().toString().replace(-, ); return Result.success(token, user); } }LoginDTO是专门接收前端请求体的对象不要直接把User实体拿来接收——实体里可能有role、createTime这些前端不应该传的字段用 DTO 隔离是防手贱传参的好办法。Result是统一返回类里面至少包含code、message、data三个字段前端拦截器只需要判断code是不是 200。接口写完后用 Postman 发一个 JSON 请求体{username:admin,password:123456}先确认后端通不通再去做前端页面不要一上来就打开 Vue 项目调接口否则分不清是前端还是后端的错。4. 前端工程化与联调Vue 项目的路由、Axios 封装、跨域三个关键动作4.1 从零初始化 Vue 3 项目并安装依赖在 IDEA 里开发 Vue 项目我习惯直接用 Vite 创建不需要 Vue CLI。Vite 启动速度快配置直观Vue 3 生态的中小型项目基本都转向 Vite 了。命令如下npm create vitelatest hanfu-web -- --template vue cd hanfu-web npm install npm install vue-router4 pinia axios element-plus安装依赖是这个环节最容易翻车的地方。国内网络环境下npm install经常卡死或报ETIMEDOUT解决办法是切换镜像源在项目根目录建.npmrc文件写入registryhttps://registry.npmmirror.com再重新装。另一个高频报错是版本冲突比如vue-router装成了 3.x和 Vue 3 根本不兼容。Vue 3必须用vue-router4别小看这个数字它就决定了你路由写法是createRouter还是new Router。4.2 Axios 拦截器统一处理 token 和错误码前端的每个需要登录态的接口都得带 token如果每个页面写一遍axios.get(url, { headers: { token: xxx } })那是噩梦。用 Axios 拦截器统一注入这算 Vue 前端面试题里被问烂了但仍然有人写不对的典型题。// request.js import axios from axios const request axios.create({ baseURL: /api, timeout: 10000 }) 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) { // token 失效跳转登录页 if (res.code 401) { localStorage.removeItem(token) window.location.href /login } return Promise.reject(new Error(res.message)) } return res }, error { console.error(请求异常:, error) return Promise.reject(error) } ) export default request这段代码的逻辑说明request实例的baseURL写成/api意思是所有请求路径省略前缀由 Vite 的 proxy 把/api开头的请求转发到后端。这样前端代码里写的是request.post(/user/login)实际发出去的是POST http://localhost:8080/api/user/login。拦截器把 token 放进请求头后端 Filter 或拦截器统一校验比每个 controller 方法里手动取 token 干净得多。响应拦截器把code 200的业务成功和 HTTP 状态码的成功区分开避免前端到处写if (res.code 200)的重复判断。4.3 联调阶段的跨域问题Vite proxy 与后端 CORS 的实际配置前后端分离必然遇到跨域。Vue 项目跑在 5173 端口后端跑在 8080 端口直接用 Axios 请求http://localhost:8080浏览器会拦截响应。解决方式有两种在 Vite 配置里做代理或者在后端开启 CORS。我推荐开发阶段用 Vite proxy因为它不改后端代码且在生产环境也不需要它——前端打包后由 Nginx 托管Nginx 反向代理到后端服务根本没有跨域一说了。Vite 配置如下// vite.config.js import { defineConfig } from vite import vue from vitejs/plugin-vue export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, // 不需要 rewrite后端接口本身带 /api 前缀 } } } })changeOrigin: true的意思是让后端看到的请求头 Host 变成localhost:8080避免某些后端框架基于 Host 做判断时误伤。如果后端接口路径不是以/api开头需要加rewrite: path path.replace(/^\/api/, )。但更省事的做法是后端所有接口统一加/api前缀这样前端和后端用的是同一套路径规则。如果前端请求发出去了浏览器 Network 面板显示 200但页面报跨域错误那说明 proxy 没生效先重启 Vite再确认请求路径确实以/api开头。5. SSM Vue 汉服平台踩坑记录5 个真实翻车案例5.1 商品图片上传到本地磁盘前端却死活访问不到现象后端接口上传图片成功数据库里存的是D:/hanfu/images/xxx.jpg前端img srcD:/hanfu/images/xxx.jpg显示破图。原因浏览器不能直接访问服务器本地磁盘路径必须通过 HTTP 访问且 SpringMVC 默认不对磁盘路径做静态资源映射。解决在 SpringMVC 配置里加资源映射把/images/**映射到本地磁盘目录。同时把图片 URL 存成相对路径即/images/xxx.jpg前端拼上后端地址即可访问。mvc:resources mapping/images/** locationfile:D:/hanfu/images/ /如果是 Spring Boot 项目则用web.config.addResourceHandlers但 SSM 项目的核心就是这个mvc:resources。另一个常见坑是上传文件名直接用原文件名用户传1.jpg和2.jpg都覆盖了所以上传后必须用 UUID 重命名。5.2 前端传过来的时间字段后端拿到的是 null现象用户在前端选了一个预计归还日期汉服租赁场景提交订单后数据库里return_time是空。原因前端传的日期格式是2025-06-30但 SpringMVC 默认的日期转换格式不支持或者实体字段类型是Date而 Jackson 反序列化时没配置格式。解决在实体字段上写JsonFormat(pattern yyyy-MM-dd HH:mm:ss)保证前端传来的字符串能正确映射。如果前端传的是时间戳数字则把字段类型改为Long在 setter 里转成Date避免序列化层与业务层互相污染。5.3 订单提交重复点击生成了两条记录现象用户下单时连续点击两次「提交订单」数据库出现两条一模一样的订单。原因前端按钮没有做防抖后端接口也没做幂等处理。解决前端在提交后立即disabled按钮并加 loading 状态后端在 service 层加一个校验比如同一用户 5 秒内不能重复提交相同金额的订单或者在订单表加一个业务唯一键。对于真正的商城项目更可靠的做法是使用分布式锁或在创建订单前校验 token 的幂等状态但毕设项目做到前后端双重拦截已经够了。注意只做前端防抖是防不住绕过前端的刷单请求的评审问到时一定要能说出后端幂等方案。5.4 首页商品列表加载快但是点击分类后页面白屏现象路由跳转到分类页面后浏览器没有报 JS 错误但页面内容是空的。原因大概率是路由匹配参数的问题。如果分类页路径是/category/:id而你在组件里用this.$route.params.id获取到的是第一次路由的缓存值或者路由表里把/category/:id写成了/category跳转时匹配不上。解决在组件里监听$route变化重新拉取数据而不是只在onMounted里加载一次。watch( () route.params.id, (newId) { if (newId) { loadList(newId) } } )用 Vue 3 的组合式 API 时route.params.id是一个响应式对象上面的写法没问题。Vue 2 项目则是watch: { $route.params.id: function() { ... } }。这类问题在控制台里往往没有任何报错排查思路就是先打日志看route.params到底是什么。5.5 后端 MyBatis 查询正常但前端总提示 500 且日志里有 SQL 异常现象调用商品列表接口前端显示 500后端日志提示Error querying database。原因通常有下面几种——数据表字段名和实体属性映射不上MyBatis 返回的结果集里有一个字段在实体里没有对应属性自动映射默认只匹配驼峰和下划线或者多表联查时重复列名导致映射字段错乱。解决先拿 SQL 去 Navicat 跑一遍确认是不是 SQL 本身的问题。SQL 没问题就看resultType对应的实体类是否所有查询字段都有对应的setter。开启 MyBatis 下划线转驼峰配置能省去大量resultMapsettings setting namemapUnderscoreToCamelCase valuetrue/ /settings这个配置的作用是自动把create_time映射到createTime如果你的数据库字段是按snake_case命名的、实体属性是camelCase这个开关能解决 80% 的映射崩溃问题。剩余 20% 是类似order这种数据库关键字SQL 里必须加反引号。6. 让代码真正属于你自己二次开发与部署验证的关键技巧拿到或者写完一套 SSM Vue 汉服平台最重要的不是跑起来而是能改得动。我的经验是先按数据流把这条链路画出来——用户打开首页、请求商品列表、加入购物车、提交订单、后台审核发货——然后对照代码在每一个环节上找出「现在的实现是什么、如果我要改需求该动哪个文件」。比如把「购物车存前端 localStorage」改成「购物车存后端数据库」你就需要动 Vue 的 store 层、后端新增 cart 表和对应的 controller / service / mapper。能说清楚每次改动涉及哪些文件才说明你读懂了这套代码。部署上本地开发用 IDEA 启动 Tomcat 加 Vite dev server生产交付则建议前端npm run build生成dist目录放到 Nginx 的html目录下Nginx 配置反向代理把/api请求转发到 Tomcat 的 8080 端口。这样把静态资源请求和动态接口请求分开性能上好、也符合汉服文化平台这类展示加交易网站的常规部署结构。如果导师或客户要求提供一个「一键启动」的演示环境那就把后端打成 WAR 包放到 Tomcat webapps 下前端 build 完也丢进同一个 Tomcat配置好上下文路径即可。验证阶段我会建议做三件事用 Postman 跑一遍核心接口的异常用例——注册重复用户名、登录错误密码、下单超卖场景、未登录访问需要鉴权的接口用浏览器的 Vue Devtools 检查路由跳转和 Pinia/Vuex 的状态变化再用生产模式npm run build后在本地起一个服务看有没有资源路径 404 的问题。这三个动作做完代码才算真正能交付。最后说一个我的习惯每次接到这类项目我都会先把数据库导出一份初始化脚本再把前端页面走一遍把所有静态资源路径记录成表。这个习惯帮我避过无数次「部署新环境发现少了个图片文件夹」「用户说页面样式乱了但其实引用的是绝对路径」的翻车事故。希望这套思路也能让你在二次开发时少走点弯路把更多时间花在真正有价值的功能上而不是和依赖、路径、编码较劲。希望帮到你。本文还有配套的精品资源点击获取
简介基于SSMVue的汉服文化平台网站是一套可直接用于毕业设计的完整Java项目面向计算机相关专业正在做毕设的学生及需要项目实战练习的Java学习者也可作为课程设计或期末大作业。项目经严格调试确保可正常运行。压缩包共867个文件约21.74MB包含Java源码、Vue组件、JavaScript脚本、HTML页面、数据库SQL脚本及开发文档等类型覆盖前端、后端、配置与文档结构清晰。内容涵盖管理员、用户及前台首页三大模块实现汉服知识管理、服装展示、用户相册、论坛交流、购物车、订单管理等完整功能。另有演示视频、部署视频、代码讲解视频及全套开发软件并附有环境说明JDK1.8、Tomcat7、MySQL5.7方便快速启动项目。已有138人学习适合需要完整可运行毕设方案和实战练习的读者。1. 从「毕设选题」到「可上线的小型电商站」SSM Vue 的汉服平台到底能做到什么程度一个汉服文化平台网站表面上是商品展示加下单实际上一旦开始动手你会碰到的是一整套 Web 工程问题用户注册登录、商品分类与检索、购物车与订单状态机、后台管理、图片上传与回显、前后端联调与跨域、部署上线。市面上很多脚手架要么只有 Spring Boot 单体要么只有 Vue 管理端真正把 SSMSpring SpringMVC MyBatis和 Vue 组合起来、又能跑通完整业务闭环的参考项目其实不多。这篇文章用一套「基于 SSM Vue 的汉服文化平台」的典型设计把从建表到联调再到部署的关键步骤拆开讲重点放在那些新手会卡住、熟手也容易忽略的边界细节上。适合正在做 Java Web 毕设的在校生也适合刚接手 SSR 老项目、想快速理解前后端分离架构的初级工程师——你可以照着这套思路复现一个最小可用版本再按自己的业务去扩展。2. 为什么用 SSM Vue而不是 Spring Boot 模板引擎选型逻辑与整体架构2.1 SSM 三件套各自管什么Spring、SpringMVC、MyBatis 的分工边界先明确一个容易被考到也容易被搞混的点SSM 不是一个框架而是三个框架的组合。Spring 负责对象管理和依赖注入SpringMVC 负责 HTTP 请求到方法的映射MyBatis 负责 SQL 与 Java 对象之间的转换。一句话总结Spring 管装配SpringMVC 管路由MyBatis 管数据。汉服平台的典型场景是前端 Vue 发一个POST /api/user/login请求Tomcat 收到后交给 DispatcherServletDispatcherServlet 通过 HandlerMapping 找到 LoginController 里的对应方法方法里调用 UserServiceUserService 再通过 UserMapper 接口找到 MyBatis 生成的代理对象最终执行 XML 里写好的 SQL把结果逐层返回。这一套链路里任何一个环节的配置断了前端只会看到 404 或 500而不会告诉你到底是哪一层出了问题——这也是很多新手第一次联调时最沮丧的地方。我在实际排查这类项目时首先会确认web.xml里的 DispatcherServlet 配置和spring-mvc.xml的组件扫描路径是否一致。比如 controller 包是com.hanfu.controller但扫描路径写成了com.hanfu.service那所有接口都会直接 404而且后端日志没有任何异常。这种问题不是代码逻辑错误而是配置漂移。2.2 Vue 2 还是 Vue 3给一个不纠结的答案很多拿到这类项目的人会问Vue 2 还是 Vue 3答案取决于你的参考项目本身。如果项目里用的是 Vue 2 Element UI vue-router 3 Vuex 3你在没有充分理由的情况下升级到 Vue 3 是给自己挖坑——Vue 3 的 Composition API、Element Plus、vue-router 4 在生态上已经有很大变化升级过程中你会花大量时间处理「看着差不多但就是不工作」的细节。但如果你是从零开始搭我建议 Vue 3 Vite Pinia。原因很实际Vue 2 已经停止维护新装的依赖经常和 Node 版本冲突Vue 3 的setup语法让组件逻辑更集中对一个商品列表加购物车的页面来说代码量反而更少。不过要注意如果你在 IDEA 里打开的是一个 Vue 2 老项目npm install时报错别急着升级版本先看 Node 版本是不是太高了Vue 2 项目配合 Node 16 通常比 Node 18 更省心。2.3 分层架构为什么 controller 不能直接写 SQL汉服平台这种规模的业务最忌讳的就是 controller 里揉进业务逻辑和 SQL。我会严格按照 controller → service → mapper → entity 四层来组织后端代码。controller 只接收参数、调用 service、返回统一结果service 写业务规则比如下单时检查库存、计算总价mapper 只写 SQL 和参数映射entity 对应数据库表结构。这样做的好处在排错时特别明显。比如订单金额算错了如果你把价格计算写在 controller 里那前端传什么参数就按什么算没有任何防御如果写在 service 里你就可以在 service 层加日志、加单元测试不用动 controller 和 SQL 就能定位问题。另一个好处是复用——后台管理端和前台商城可能都需要查订单列表两个 controller 共用一个 service 方法参数不同而已。依赖方向必须单向controller 依赖 serviceservice 依赖 mapper谁都不能反向。如果你发现某个 mapper 方法里又调了 service说明设计已经乱了趁早重构。3. 从数据库设计到第一个能跑的登录接口核心表与 MyBatis 实战3.1 汉服平台的表结构设计用户、商品、订单、收藏四张表就够了一套能支撑「静态展示 购物下单 后台管理」的汉服平台最少需要这几张表用户表user、汉服商品表costume、订单表order、订单明细表order_item、收藏表favorite再加一个分类表category。不要一开始就设计十几张表业务没到那一步表越多联调越痛苦。用户表的设计有个容易踩的坑密码字段。明文存储是绝对不能接受的我用的是 BCrypt 加密Spring Security 里自带BCryptPasswordEncoder不引 Security 的话可以用 jBCrypt 的独立库。加密的意义在于数据库泄露时攻击者拿到的是一串随机散列而不是用户的原始密码。对于毕设项目这是评委一定会问的点。商品表需要注意的字段是「上下架状态」和「库存」。状态字段用TINYINT0 表示下架、1 表示上架比用字符串有效率得多。库存字段不能只是展示用下单时要扣减所以它必须参与事务。CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT, username VARCHAR(50) NOT NULL, password VARCHAR(100) NOT NULL, nickname VARCHAR(50) DEFAULT NULL, avatar VARCHAR(255) DEFAULT NULL, role TINYINT DEFAULT 0 COMMENT 0-普通用户 1-管理员, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; CREATE TABLE costume ( id INT NOT NULL AUTO_INCREMENT, category_id INT DEFAULT NULL, name VARCHAR(100) NOT NULL, description TEXT, price DECIMAL(10,2) NOT NULL, stock INT NOT NULL DEFAULT 0, image VARCHAR(255) DEFAULT NULL, status TINYINT DEFAULT 1 COMMENT 0-下架 1-上架, create_time DATETIME DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这两张表的细节提醒所有字符串字段用utf8mb4而不是utf8否则用户填的生僻字或 Emoji 表情会报Incorrect string value错误。密码字段长度预留 100 是因为 BCrypt 加密后的字符串长度是 60但保险起见给足余量。UNIQUE KEY加在用户名上是必须的否则注册接口会重复插入数据。3.2 用 MyBatis 写动态 SQL商品列表和条件筛选商城的商品列表页不可能只有一个SELECT * FROM costume用户会按分类筛选、按价格排序、搜关键字。这些条件组合在 MyBatis 里用where标签加if判断来实现避免手动拼接 SQL 时漏掉WHERE关键字或者多出一个AND。select idlistByCondition resultTypecom.hanfu.entity.Costume SELECT id, category_id, name, description, price, stock, image, status FROM costume where if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND name LIKE CONCAT(%, #{keyword}, %) /if if teststatus ! null AND status #{status} /if /where if testorderBy ! null and orderBy ! ORDER BY ${orderBy} /if LIMIT #{offset}, #{pageSize} /select这里有两个关键点。第一#{}和${}的区别#{}是预编译参数占位符MyBatis 会生成?能防 SQL 注入${}是字符串拼接直接把值拼进 SQL永远不要用${}接收前端传的值。上面代码里ORDER BY ${orderBy}是有意为之因为排序字段不能参数化但必须在 service 层做白名单校验只允许传入price ASC、price DESC、create_time DESC这几个固定值。第二CONCAT(%, #{keyword}, %)不要写成%${keyword}%后者有注入风险。模糊搜索在数据量小的时候用 LIKE 没问题数据量过百万再考虑全文索引或 Elasticsearch现阶段不用过度设计。3.3 登录接口的前后实现与 Postman 验证登录是第一个联调接口跑通了它后面所有接口的套路都是一样的。后端用一个LoginController接收参数service 里校验用户名密码成功则返回用户信息和一个 token。RestController RequestMapping(/api/user) public class LoginController { Resource private UserService userService; PostMapping(/login) public Result login(RequestBody LoginDTO dto) { if (dto.getUsername() null || dto.getPassword() null) { return Result.error(用户名和密码不能为空); } User user userService.login(dto.getUsername(), dto.getPassword()); if (user null) { return Result.error(用户名或密码错误); } // 登录成功生成 token实际项目用 JWT 或 Redis 会话 String token UUID.randomUUID().toString().replace(-, ); return Result.success(token, user); } }LoginDTO是专门接收前端请求体的对象不要直接把User实体拿来接收——实体里可能有role、createTime这些前端不应该传的字段用 DTO 隔离是防手贱传参的好办法。Result是统一返回类里面至少包含code、message、data三个字段前端拦截器只需要判断code是不是 200。接口写完后用 Postman 发一个 JSON 请求体{username:admin,password:123456}先确认后端通不通再去做前端页面不要一上来就打开 Vue 项目调接口否则分不清是前端还是后端的错。4. 前端工程化与联调Vue 项目的路由、Axios 封装、跨域三个关键动作4.1 从零初始化 Vue 3 项目并安装依赖在 IDEA 里开发 Vue 项目我习惯直接用 Vite 创建不需要 Vue CLI。Vite 启动速度快配置直观Vue 3 生态的中小型项目基本都转向 Vite 了。命令如下npm create vitelatest hanfu-web -- --template vue cd hanfu-web npm install npm install vue-router4 pinia axios element-plus安装依赖是这个环节最容易翻车的地方。国内网络环境下npm install经常卡死或报ETIMEDOUT解决办法是切换镜像源在项目根目录建.npmrc文件写入registryhttps://registry.npmmirror.com再重新装。另一个高频报错是版本冲突比如vue-router装成了 3.x和 Vue 3 根本不兼容。Vue 3必须用vue-router4别小看这个数字它就决定了你路由写法是createRouter还是new Router。4.2 Axios 拦截器统一处理 token 和错误码前端的每个需要登录态的接口都得带 token如果每个页面写一遍axios.get(url, { headers: { token: xxx } })那是噩梦。用 Axios 拦截器统一注入这算 Vue 前端面试题里被问烂了但仍然有人写不对的典型题。// request.js import axios from axios const request axios.create({ baseURL: /api, timeout: 10000 }) 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) { // token 失效跳转登录页 if (res.code 401) { localStorage.removeItem(token) window.location.href /login } return Promise.reject(new Error(res.message)) } return res }, error { console.error(请求异常:, error) return Promise.reject(error) } ) export default request这段代码的逻辑说明request实例的baseURL写成/api意思是所有请求路径省略前缀由 Vite 的 proxy 把/api开头的请求转发到后端。这样前端代码里写的是request.post(/user/login)实际发出去的是POST http://localhost:8080/api/user/login。拦截器把 token 放进请求头后端 Filter 或拦截器统一校验比每个 controller 方法里手动取 token 干净得多。响应拦截器把code 200的业务成功和 HTTP 状态码的成功区分开避免前端到处写if (res.code 200)的重复判断。4.3 联调阶段的跨域问题Vite proxy 与后端 CORS 的实际配置前后端分离必然遇到跨域。Vue 项目跑在 5173 端口后端跑在 8080 端口直接用 Axios 请求http://localhost:8080浏览器会拦截响应。解决方式有两种在 Vite 配置里做代理或者在后端开启 CORS。我推荐开发阶段用 Vite proxy因为它不改后端代码且在生产环境也不需要它——前端打包后由 Nginx 托管Nginx 反向代理到后端服务根本没有跨域一说了。Vite 配置如下// vite.config.js import { defineConfig } from vite import vue from vitejs/plugin-vue export default defineConfig({ plugins: [vue()], server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, // 不需要 rewrite后端接口本身带 /api 前缀 } } } })changeOrigin: true的意思是让后端看到的请求头 Host 变成localhost:8080避免某些后端框架基于 Host 做判断时误伤。如果后端接口路径不是以/api开头需要加rewrite: path path.replace(/^\/api/, )。但更省事的做法是后端所有接口统一加/api前缀这样前端和后端用的是同一套路径规则。如果前端请求发出去了浏览器 Network 面板显示 200但页面报跨域错误那说明 proxy 没生效先重启 Vite再确认请求路径确实以/api开头。5. SSM Vue 汉服平台踩坑记录5 个真实翻车案例5.1 商品图片上传到本地磁盘前端却死活访问不到现象后端接口上传图片成功数据库里存的是D:/hanfu/images/xxx.jpg前端img srcD:/hanfu/images/xxx.jpg显示破图。原因浏览器不能直接访问服务器本地磁盘路径必须通过 HTTP 访问且 SpringMVC 默认不对磁盘路径做静态资源映射。解决在 SpringMVC 配置里加资源映射把/images/**映射到本地磁盘目录。同时把图片 URL 存成相对路径即/images/xxx.jpg前端拼上后端地址即可访问。mvc:resources mapping/images/** locationfile:D:/hanfu/images/ /如果是 Spring Boot 项目则用web.config.addResourceHandlers但 SSM 项目的核心就是这个mvc:resources。另一个常见坑是上传文件名直接用原文件名用户传1.jpg和2.jpg都覆盖了所以上传后必须用 UUID 重命名。5.2 前端传过来的时间字段后端拿到的是 null现象用户在前端选了一个预计归还日期汉服租赁场景提交订单后数据库里return_time是空。原因前端传的日期格式是2025-06-30但 SpringMVC 默认的日期转换格式不支持或者实体字段类型是Date而 Jackson 反序列化时没配置格式。解决在实体字段上写JsonFormat(pattern yyyy-MM-dd HH:mm:ss)保证前端传来的字符串能正确映射。如果前端传的是时间戳数字则把字段类型改为Long在 setter 里转成Date避免序列化层与业务层互相污染。5.3 订单提交重复点击生成了两条记录现象用户下单时连续点击两次「提交订单」数据库出现两条一模一样的订单。原因前端按钮没有做防抖后端接口也没做幂等处理。解决前端在提交后立即disabled按钮并加 loading 状态后端在 service 层加一个校验比如同一用户 5 秒内不能重复提交相同金额的订单或者在订单表加一个业务唯一键。对于真正的商城项目更可靠的做法是使用分布式锁或在创建订单前校验 token 的幂等状态但毕设项目做到前后端双重拦截已经够了。注意只做前端防抖是防不住绕过前端的刷单请求的评审问到时一定要能说出后端幂等方案。5.4 首页商品列表加载快但是点击分类后页面白屏现象路由跳转到分类页面后浏览器没有报 JS 错误但页面内容是空的。原因大概率是路由匹配参数的问题。如果分类页路径是/category/:id而你在组件里用this.$route.params.id获取到的是第一次路由的缓存值或者路由表里把/category/:id写成了/category跳转时匹配不上。解决在组件里监听$route变化重新拉取数据而不是只在onMounted里加载一次。watch( () route.params.id, (newId) { if (newId) { loadList(newId) } } )用 Vue 3 的组合式 API 时route.params.id是一个响应式对象上面的写法没问题。Vue 2 项目则是watch: { $route.params.id: function() { ... } }。这类问题在控制台里往往没有任何报错排查思路就是先打日志看route.params到底是什么。5.5 后端 MyBatis 查询正常但前端总提示 500 且日志里有 SQL 异常现象调用商品列表接口前端显示 500后端日志提示Error querying database。原因通常有下面几种——数据表字段名和实体属性映射不上MyBatis 返回的结果集里有一个字段在实体里没有对应属性自动映射默认只匹配驼峰和下划线或者多表联查时重复列名导致映射字段错乱。解决先拿 SQL 去 Navicat 跑一遍确认是不是 SQL 本身的问题。SQL 没问题就看resultType对应的实体类是否所有查询字段都有对应的setter。开启 MyBatis 下划线转驼峰配置能省去大量resultMapsettings setting namemapUnderscoreToCamelCase valuetrue/ /settings这个配置的作用是自动把create_time映射到createTime如果你的数据库字段是按snake_case命名的、实体属性是camelCase这个开关能解决 80% 的映射崩溃问题。剩余 20% 是类似order这种数据库关键字SQL 里必须加反引号。6. 让代码真正属于你自己二次开发与部署验证的关键技巧拿到或者写完一套 SSM Vue 汉服平台最重要的不是跑起来而是能改得动。我的经验是先按数据流把这条链路画出来——用户打开首页、请求商品列表、加入购物车、提交订单、后台审核发货——然后对照代码在每一个环节上找出「现在的实现是什么、如果我要改需求该动哪个文件」。比如把「购物车存前端 localStorage」改成「购物车存后端数据库」你就需要动 Vue 的 store 层、后端新增 cart 表和对应的 controller / service / mapper。能说清楚每次改动涉及哪些文件才说明你读懂了这套代码。部署上本地开发用 IDEA 启动 Tomcat 加 Vite dev server生产交付则建议前端npm run build生成dist目录放到 Nginx 的html目录下Nginx 配置反向代理把/api请求转发到 Tomcat 的 8080 端口。这样把静态资源请求和动态接口请求分开性能上好、也符合汉服文化平台这类展示加交易网站的常规部署结构。如果导师或客户要求提供一个「一键启动」的演示环境那就把后端打成 WAR 包放到 Tomcat webapps 下前端 build 完也丢进同一个 Tomcat配置好上下文路径即可。验证阶段我会建议做三件事用 Postman 跑一遍核心接口的异常用例——注册重复用户名、登录错误密码、下单超卖场景、未登录访问需要鉴权的接口用浏览器的 Vue Devtools 检查路由跳转和 Pinia/Vuex 的状态变化再用生产模式npm run build后在本地起一个服务看有没有资源路径 404 的问题。这三个动作做完代码才算真正能交付。最后说一个我的习惯每次接到这类项目我都会先把数据库导出一份初始化脚本再把前端页面走一遍把所有静态资源路径记录成表。这个习惯帮我避过无数次「部署新环境发现少了个图片文件夹」「用户说页面样式乱了但其实引用的是绝对路径」的翻车事故。希望这套思路也能让你在二次开发时少走点弯路把更多时间花在真正有价值的功能上而不是和依赖、路径、编码较劲。希望帮到你。本文还有配套的精品资源点击获取
