简介基于SpringBoot与Vue构建的二次元商品购物商城系统完整项目包面向计算机相关专业毕业设计学生、课程设计及Java实战学习者。系统聚焦用户端完整购物链路首页展示贴合二次元主题的轻松界面商品分类模块陈列全部商品列表个人中心支持地址管理、订单列表、购物车管理、商品收藏以及退出登录功能覆盖全面且经过严格调试可直接运行。资源包共716个文件约62.17MB以jpg/png图片素材、java后端源码、js/css前端资源及xml/sql数据库与配置脚本为主附带数据库脚本、部署说明文档、LW论文、演示视频及目录结构说明从环境搭建、数据初始化到前后端联调均可按文档复现。目前已有209人学习下载适合需要完整参考方案、快速上手毕设或进行二次功能扩展的场景。项目源码、数据库脚本与配套文档一应俱全结合演示视频可降低理解门槛便于对照检查实现效果。1. 二次元商城系统值不值得自己写SpringBootVue的取舍与适用场景做手办、谷子、cos道具这类二次元商品生意多半会碰到一个尴尬进大平台要被抽成用现成的商城SaaS又绑手绑脚一个手办分普通版、特典版、再版预售定金玩法模板很难贴。自己用SpringBootVue从零搭一套商城系统正好卡在“成本可控”和“需求贴合”之间。这个标题讲的是务实的前后端分离商城不是花哨的微服务架构SpringBoot撑起商品、购物车、订单、支付对接的APIVue负责用户端和管理端页面配合能导入即用的数据库脚本和项目文档把电商最小闭环跑通。适合三类人拿来做毕业设计的学生、想做私域商城的小团队、想完整走一遍全栈项目的老手。下面从后端、前端、数据库一路到避坑和验证把这套方案讲透。2. SpringBoot后端骨架从依赖选型到三层架构落地的关键配置后端是整个系统的承重墙。很多人栽跟头不是因为功能多难写而是依赖版本和包结构一开始就乱了。先把后端拆清楚再谈功能后面能少走很多弯路。2.1 SpringBoot项目结构与依赖选型一个商城后端该拆几个模块先说项目结构。商城系统后端不需要一上来就拆微服务单体应用加清晰分包是最稳的。常见做法是单模块按功能分包controller、service、mapper、entity、config、common、utils。这样文件不散落一地也没有模块间依赖的心智负担对“源码数据库文档”这种交付场景特别合适——别人解开压缩包目录一眼能看懂答辩讲架构也省力气。我见过不少项目把controller写成上帝类一个类里塞几十个接口改一个功能要翻半天。更合理的拆法是把商品、购物车、订单、用户分成独立的业务包每个包内再分controller、service、mapper。配合SpringBoot自动扫描几乎是零成本维护。还有一点要注意controller里不要直接操作数据库。很多人图快把mapper直接注入controller看起来省了一层但事务注解和业务校验就没地方放了。Service层哪怕再薄也要留后面加缓存、加库存锁定都只改service不动接口。依赖选型有几个关键决定。数据库访问层我一般用MyBatis-Plus而不是纯MyBatis它能省掉大量单表增删改查的样板代码分页插件、乐观锁插件都是现成的对商城这种CRUD密集的系统很划算。鉴权用JWT理由是它无状态后端不存会话用户端App和Web可以复用同一套登录逻辑。文件上传在开发期用本地存储加nginx映射就行不必为一个小商城专门引对象存储SDK。核心依赖如下parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.5/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency /dependencies版本这块多说一句。spring-boot-starter-parent选2.7.x这一代比较稳妥它对应JDK8跟MyBatis-Plus、jjwt的兼容性被大量项目验证过。SpringBoot 3.x虽然新但要求JDK17起步如果机器上还是JDK8启动时一堆版本报错会非常劝退。mysql-connector-java在2.7.x里用这个坐标到3.x改名为com.mysql:mysql-connector-j这也是很多人升级后踩的第一个坑。2.2 整合MyBatis-Plus与JWT鉴权把配置写对少走弯路依赖加完轮到application.yml。这里配置决定后面能不能少改代码。我会把端口、数据库、MyBatis-Plus、JWT密钥分开写清楚server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/anime_mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: id-type: auto logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0参数说明serverTimezoneAsia/Shanghai必须加不然MySQL 8时区校验直接报错。map-underscore-to-camel-case: true让数据库的create_time自动映射实体的createTime不用手写一堆resultMap。logic-delete字段是逻辑删除商城系统的订单和商品最好不要物理删不然对账和追溯很难受。log-impl配成StdOutImpl后开发期能在控制台直接看到每条SQL排查数据问题非常管用上线前记得关掉。JWT这块我习惯抽一个JwtUtil类负责生成和解析token再写拦截器统一校验。核心思路是用户登录成功发token前端存localStorage每次请求在Authorization头带上拦截器校验通过后把userId塞进request attribute。一个容易忽略的细节jjwt 0.9.1的parse方法依赖jaxbJDK8以上需要补上jaxb-api依赖不然运行时抛ClassNotFoundException。这属于典型的黑匣子问题不看堆栈根本想不到是缺jar。2.3 商品与订单的API设计接口路径与返回统一格式结构搭好、鉴权通了就该定接口契约。我坚持所有接口返回统一格式前端不用为各种返回各写一套判断。格式是code、message、data三件套200表示成功401表示未登录500表示服务端异常。接口路径按资源命名比如模块路径方法说明商品/api/goods/{id}GET商品详情商品/api/goods/pageGET分页商品列表支持关键字和分类筛选购物车/api/cart/{userId}GET查询用户购物车购物车/api/cart/addPOST加入购物车订单/api/order/createPOST创建订单订单/api/order/{orderNo}GET订单详情支付/api/pay/notifyPOST支付回调这个表前后端各拿一份开发期就可以用Swagger或Apifox去调不用等全部写完。创建订单接口必须走POST它涉及事务和库存操作用GET会在浏览器缓存和日志里留下脏数据。列表接口加分页参数pageNum和pageSize返回结构里带total前端直接渲染分页条。管理端接口和用户端接口都走/api前缀但按模块区分比如/admin/order是管理端查询/api/order/create是用户端下单别混在一起。3. Vue前端与后端联调路由、状态管理与接口对接后端API立起来后前端就是门面。二次元商城的前端有两个特点一是商品图多对图片懒加载有要求二是购物车、订单状态在页面间跳转时需要共享不能每个页面都重新拉接口。这就决定了前端不只是写页面还要把路由、状态管理、接口封装先定好。3.1 Vue项目初始化与路由设计从安装依赖到页面骨架常见做法是用Vue CLI或Vite创建项目。Vite启动快但Vue CLI对新手更友好文档多。如果源码是Vue 2路由就是vue-router 3.x如果是Vue 3就配vue-router 4.x。拿到源码第一件事先看package.json里的vue和vue-router版本版本不匹配是前端跑不起来的头号原因。安装依赖这一步很多人直接npm install然后卡在node-sass或者Python环境上。我的一般做法是删掉package-lock.json再npm install。这种交付型的项目别人拿到源码后最关心的是怎么最快跑起来而不是先读一大段README。装完依赖路由配置放在src/router/index.jsVue 2的写法是import Vue from vue import VueRouter from vue-router Vue.use(VueRouter) const routes [ { path: /, component: () import(/views/Home.vue), meta: { title: 首页 } }, { path: /goods/:id, component: () import(/views/GoodsDetail.vue), meta: { title: 商品详情 } }, { path: /cart, component: () import(/views/Cart.vue), meta: { title: 购物车, requiresAuth: true } }, { path: /order/confirm, component: () import(/views/OrderConfirm.vue), meta: { title: 确认订单, requiresAuth: true } }, { path: /login, component: () import(/views/Login.vue) }, { path: *, redirect: / } ] const router new VueRouter({ mode: history, routes }) router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) } else { next() } }) export default router这里有几个点要说明。路由懒加载用箭头函数import首页不会把商品详情页的代码一起下下来。requiresAuth是路由元信息配合beforeEach做登录守卫比在每个页面里判断干净得多。mode: history让URL不带#号好看但打包后部署必须让后端或nginx配fallback否则刷新就404这个坑在第5章细说。开发期嫌麻烦就先用默认的hash模式最省心。3.2 Axios封装与接口对接统一处理Token和错误码页面组件里直接fetch不现实几十个接口每个都写一遍错误处理代码会膨胀到没法维护。我习惯在src/utils/request.js里封装axios拦截器统一做三件事带token、处理业务错误码、弹全局消息。import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] token } return config }) service.interceptors.response.use( response { const res response.data if (res.code 200) { return res.data } if (res.code 401) { localStorage.removeItem(token) router.push(/login) } Message.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) }, error { Message.error(error.message || 网络异常) return Promise.reject(error) } ) export default service这段封装的价值在联调阶段体现得最明显。baseURL设成/api开发期由webpack或Vite代理转发到后端8080端口上线后由nginx把/api转发到Java进程前端代码本身不用区分环境。拦截器里return res.data组件里直接拿数据本体不用每处解一层壳。401统一踢回登录页避免每个接口单独判断。3.3 商品列表与购物车的状态管理用Pinia还是Vuex当商品筛选条件、购物车数量、订单确认信息需要在多个组件间共享时就该上状态管理了。Vue 2项目用VuexVue 3项目更推荐Pinia。Pinia删掉了mutations概念逻辑更直观对TypeScript支持更好Vuex在Vue 2里生态成熟网上资料多。选型原则很简单跟着项目里的Vue版本来不要强行跨版本。如果这套源码是Vue 2 Vuex 3硬改成Pinia会引出一堆兼容问题。购物车的核心状态是items数组和totalPrice计算属性变更逻辑集中在add、remove、updateQuantity三个action里配合localStorage持久化页面刷新购物车不丢。这块没有太多玄学主要是把action命名统一别把状态修改散落在各个组件里。3.4 UI组件库与图片懒加载二次元商城的前端性能线二次元商城的商品图动辄上百张首页一次加载十几个商品就可能让页面卡顿。管理端基于Element UI可以很快把表格、弹窗、表单搭出来用户端则要注意图片懒加载。Vue 2下用vue-lazyload插件main.js里注册模板里把img src改成v-lazy。商品详情页的图片数组循环渲染配合过渡动画就有基本可用体验。懒加载的阈值要根据页面布局调不要在用户还没滚动到位置时就加载全部图片。购物车页面的图片尺寸要压缩详情页再用大图同一张图两个size字段别在列表页拖原图。样式这块二次元风格靠CSS变量做主题色切换主色、辅色、价格色各一个变量后续做活动专题页能省不少事。4. 数据库设计与订单链路五张核心表的事务边界商城系统的问题最终都在数据库里暴露。二次元商品比普通商品多了一层复杂性一个商品有普通版、特典版、再版每个版本可能有不同封面图、特典赠品和价格。数据库设计如果在一张表里把这些全塞进去后面改起来就是灾难。4.1 商品SPU与SKU拆分为什么二次元商品不能只用一张表SPU是商品抽象比如“某某手办 1/7比例 普通版”SKU是具体可下单的售卖单元比如“普通版-日版”“特典版-代理版”。电商规范做法是SPU表存商品公共信息SKU表存价格、库存、规格编码。二次元商品尤其需要这样拆一套手办可能有多个版本共享同一套详情图和描述但价格和库存完全不同。核心表我一般这样建CREATE TABLE spu ( id bigint NOT NULL AUTO_INCREMENT, title varchar(128) NOT NULL COMMENT 商品标题, subtitle varchar(255) DEFAULT NULL COMMENT 副标题, main_image varchar(255) NOT NULL COMMENT 主图URL, detail_html text COMMENT 详情页富文本, brand_id bigint DEFAULT NULL COMMENT 品牌ID, category_id bigint DEFAULT NULL COMMENT 分类ID, status tinyint DEFAULT 1 COMMENT 1上架 0下架, deleted tinyint DEFAULT 0 COMMENT 逻辑删除, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品SPU表; CREATE TABLE sku ( id bigint NOT NULL AUTO_INCREMENT, spu_id bigint NOT NULL COMMENT 所属SPU, sku_name varchar(128) NOT NULL COMMENT 如普通版-日版, price decimal(10,2) NOT NULL COMMENT 售价, stock int NOT NULL DEFAULT 0 COMMENT 库存, version int DEFAULT 0 COMMENT 乐观锁版本号, deleted tinyint DEFAULT 0, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_spu_id (spu_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品SKU表;字符集用utf8mb4而不是utf8因为二次元商品标题里经常有emoji和特殊符号utf8mb4才存得下。detail_html用text类型详情页富文本图片多大字段单独放不拖慢列表查询。deleted字段配合MyBatis-Plus逻辑删除管理端删错商品还能有后悔药这是电商运营的刚需。4.2 订单状态机与库存扣减并发场景下怎么保证不超卖订单表承载了整条链路。订单号建议用业务单号不用自增id格式带日期和随机数比如20250607153000123456对账和查单都方便。订单扣库存是并发问题高发区。两个用户同时买最后一个手办如果先查库存再更新必然有一个请求读到旧值导致超卖。解决办法是更新时加库存条件影响行数为0就当失败UPDATE sku SET stock stock - 1, version version 1 WHERE id #{skuId} AND stock 0;这条SQL对应的Java逻辑要包在事务里先扣库存再创建订单任何一步失败整体回滚。MyBatis-Plus自带乐观锁插件但直接用这条条件更新SQL反而更直观。注意事务边界减库存、生成订单、清购物车三个操作必须在同一个事务方法里不要拆成三个接口在前端依次调用否则中间任何一个失败数据就悬空了。订单状态建议用tinyint存0待支付、1已支付、2已发货、3已完成、4已取消状态流转写在一个枚举类里不要散落到处是魔法数字。4.3 数据库增删改查与结构变更开发期怎么管理SQL脚本拿到数据库文件第一件事是用source命令导入然后花十分钟做数据库增删改查的基础验证查一遍SPU、SKU、订单表的关联关系是否完整商品数据能不能查到库存和订单对得上。开发期的表结构会频繁调整。我见过最痛心的做法是在Navicat里手改表然后代码和数据库对不上只能靠肉眼排查。建议所有结构变更写成增量SQL脚本按日期编号放在sql目录下-- 20250607_init.sql CREATE DATABASE IF NOT EXISTS anime_mall DEFAULT CHARACTER SET utf8mb4; USE anime_mall; -- 其余建表语句…… -- 20250608_alter_sku.sql ALTER TABLE sku ADD COLUMN origin_price decimal(10,2) DEFAULT NULL COMMENT 原价 AFTER price; ALTER TABLE sku MODIFY COLUMN sku_name varchar(256) NOT NULL COMMENT SKU名称支持加长标题;脚本式管理结构变更的好处是换机器、换人、回滚都能追溯。配合Flyway可以启动自动执行但对这种直接给源码和数据库文件的交付项目手动脚本加文档说明已经足够。记住数据库脚本和代码一样需要版本管理别让Navicat的导出文件成为唯一真相。5. 二次元商城开发避坑图片、跨域、打包与支付下面这些是实战里淌出来的。五类问题按出现频率排序每个都是真实翻车点。5.1 商品图片加载失败与防盗链问题现象商品列表图在本地好好的部署到服务器后大量裂图控制台报403或混合内容错误。原因二次元商品图经常从画师或合作方站点引用很多站点了防盗链检查Referer非白名单域名一律拒绝。部署后域名变了引用自然失效。另外如果站点是https资源是http浏览器直接拦截。解决商品图必须全部落到自己的存储。开发期本地目录加nginx映射上线后统一走对象存储。数据库里存相对路径而不是完整URL比如/goods/2025/06/07/xxx.jpg由部署环境拼接域名这样从http切https不需要改库。还有一个小坑图片文件名不要用中文和空格部分旧版nginx对中文URL编码处理不一致会随机404。5.2 前后端联调时的跨域配置现象前端npm run dev端口是3000后端8080浏览器直接请求接口报“Access-Control-Allow-Origin”错误。原因浏览器同源策略前后端端口不同就触发跨域。解决开发期最省事的做法是在Vue的vue.config.js里配proxy而不是在后端开CORS放行module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }生产环境用nginx反代同源后端开CORS反而放开一个安全面没必要。如果坚持后端开CORS要注意预检请求OPTIONSSpringBoot要配allowedOriginPatterns而不是allowedOrigins后者在带凭证的请求下会报错。这个区别很隐蔽界面上一模一样的配置一个能跑一个不能跑。5.3 库存超卖与重复下单现象活动价手办上线秒空但后台订单数比初始库存多或者用户双击提交按钮生成了两笔相同订单。原因库存扣减没有条件判断下单接口没有做重复提交处理。解决库存问题按4.2的update语句解决。重复下单一般两个手段前端按钮提交后立刻disabled后端对同一用户同一SKU在一定时间窗口内做幂等校验常见做法是前端生成requestId后端用Redis存已处理请求——没有Redis就用数据库唯一索引兜底。别小看这个支付系统回调和用户手滑都会把重复订单问题放大。我发现很多人在测试环境测不出这个问题是因为测试工具不会模拟双击建议用脚本对下单接口压一发很快就能暴露。5.4 vue打包放进SpringBoot后路由刷新404现象npm run build之后把dist目录放进SpringBoot的static目录从首页点进商品详情没问题一刷新页面就是404。原因前端是history路由模式URL路径对后端来说不存在对应静态文件SpringBoot默认找不到资源就返回404。解决两种做法。第一种最简单路由改回hash模式URL带#不用后端做任何配置。第二种是后端实现一个转发兜底把不带点后缀的路径统一转发到index.htmlController public class SpaController { RequestMapping(value /{path:[^\\.]*}, method RequestMethod.GET) public String forwardSingle() { return forward:/index.html; } }这段配置只处理单层路径像/admin/dashboard这种多级路径还需要再加一层/**的映射正则写起来很啰嗦。所以我的推荐是彻底用nginx托管前端静态文件只在nginx层做fallbackSpringBoot专心做API。前后端彻底分家更新前端不用重新打后端jar包这才是vue放进springboot最省心的姿势。5.5 支付回调的幂等处理现象支付平台侧回调连发三次每次都更新订单状态、加积分用户支付一次被加三次积分。原因支付回调大部分是支付平台的异步通知可能多次到达后端必须先判断订单当前状态再处理。解决回调处理函数开头加状态校验如果订单已经是“已支付”直接返回成功标记给支付平台不重复执行业务逻辑。同时支付回调业务用try-catch包住捕获异常时记录日志并返回失败让平台重试但一定不能重试幂等消费的部分。用沙箱环境把回调重发、延迟回调、重复回调三种情况都测一遍再上线。测试环境还要注意回调地址必须是公网能访问的很多人卡在这步不是代码问题而是本地ngrok没配好回调根本到不了后端。6. 从源码到可演示最小启动命令与三个验证点6.1 先跑通再读文档最小启动顺序与三个验证点拿到这份源码、数据库和文档按这个顺序跑别跳步用Navicat或命令行source命令导入sql文件确认anime_mall库建好SPU、SKU、订单表里都有数据。改application.yml里的数据库账号密码先别动其他配置。后端目录执行mvn spring-boot:run看到Tomcat started on port 8080就算起来了。前端目录npm install、npm run dev浏览器打开本地地址。跑起来后验证三个关键点就说明链路是通的验证点方法期望结果登录鉴权用管理端账号登录看Network里请求是否带Authorization头登录成功访问受保护接口返回200商品链路列表页点商品进详情加购物车再结算库存减少1购物车数量正确支付回调用沙箱支付后触发回调观察后端日志订单状态变为已支付且只更新一次我个人的习惯是这三步跑通后再去读文档里的接口说明比从头读文档快得多。运行期遇到端口占用、数据库连接失败先看堆栈前五行八成是配置问题而不是代码问题。端口冲突时用lsof -i:8080找占用进程数据库连不上就先telnet 3306不要一上来就怀疑代码。最后说一句血泪经验不要因为急着演示而跳过支付回调的幂等验证。我遇到过最尴尬的一次就是演示下单时支付回调重试导致订单状态反复跳当场翻车。把启动和验证流程按上面这套固化下来后面加功能、改需求都稳。希望帮到你。本文还有配套的精品资源点击获取
SpringBoot+Vue二次元商城系统实战：从架构设计到部署避坑指南
简介基于SpringBoot与Vue构建的二次元商品购物商城系统完整项目包面向计算机相关专业毕业设计学生、课程设计及Java实战学习者。系统聚焦用户端完整购物链路首页展示贴合二次元主题的轻松界面商品分类模块陈列全部商品列表个人中心支持地址管理、订单列表、购物车管理、商品收藏以及退出登录功能覆盖全面且经过严格调试可直接运行。资源包共716个文件约62.17MB以jpg/png图片素材、java后端源码、js/css前端资源及xml/sql数据库与配置脚本为主附带数据库脚本、部署说明文档、LW论文、演示视频及目录结构说明从环境搭建、数据初始化到前后端联调均可按文档复现。目前已有209人学习下载适合需要完整参考方案、快速上手毕设或进行二次功能扩展的场景。项目源码、数据库脚本与配套文档一应俱全结合演示视频可降低理解门槛便于对照检查实现效果。1. 二次元商城系统值不值得自己写SpringBootVue的取舍与适用场景做手办、谷子、cos道具这类二次元商品生意多半会碰到一个尴尬进大平台要被抽成用现成的商城SaaS又绑手绑脚一个手办分普通版、特典版、再版预售定金玩法模板很难贴。自己用SpringBootVue从零搭一套商城系统正好卡在“成本可控”和“需求贴合”之间。这个标题讲的是务实的前后端分离商城不是花哨的微服务架构SpringBoot撑起商品、购物车、订单、支付对接的APIVue负责用户端和管理端页面配合能导入即用的数据库脚本和项目文档把电商最小闭环跑通。适合三类人拿来做毕业设计的学生、想做私域商城的小团队、想完整走一遍全栈项目的老手。下面从后端、前端、数据库一路到避坑和验证把这套方案讲透。2. SpringBoot后端骨架从依赖选型到三层架构落地的关键配置后端是整个系统的承重墙。很多人栽跟头不是因为功能多难写而是依赖版本和包结构一开始就乱了。先把后端拆清楚再谈功能后面能少走很多弯路。2.1 SpringBoot项目结构与依赖选型一个商城后端该拆几个模块先说项目结构。商城系统后端不需要一上来就拆微服务单体应用加清晰分包是最稳的。常见做法是单模块按功能分包controller、service、mapper、entity、config、common、utils。这样文件不散落一地也没有模块间依赖的心智负担对“源码数据库文档”这种交付场景特别合适——别人解开压缩包目录一眼能看懂答辩讲架构也省力气。我见过不少项目把controller写成上帝类一个类里塞几十个接口改一个功能要翻半天。更合理的拆法是把商品、购物车、订单、用户分成独立的业务包每个包内再分controller、service、mapper。配合SpringBoot自动扫描几乎是零成本维护。还有一点要注意controller里不要直接操作数据库。很多人图快把mapper直接注入controller看起来省了一层但事务注解和业务校验就没地方放了。Service层哪怕再薄也要留后面加缓存、加库存锁定都只改service不动接口。依赖选型有几个关键决定。数据库访问层我一般用MyBatis-Plus而不是纯MyBatis它能省掉大量单表增删改查的样板代码分页插件、乐观锁插件都是现成的对商城这种CRUD密集的系统很划算。鉴权用JWT理由是它无状态后端不存会话用户端App和Web可以复用同一套登录逻辑。文件上传在开发期用本地存储加nginx映射就行不必为一个小商城专门引对象存储SDK。核心依赖如下parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version2.7.18/version relativePath/ /parent dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-validation/artifactId /dependency dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.5/version /dependency dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency dependency groupIdio.jsonwebtoken/groupId artifactIdjjwt/artifactId version0.9.1/version /dependency /dependencies版本这块多说一句。spring-boot-starter-parent选2.7.x这一代比较稳妥它对应JDK8跟MyBatis-Plus、jjwt的兼容性被大量项目验证过。SpringBoot 3.x虽然新但要求JDK17起步如果机器上还是JDK8启动时一堆版本报错会非常劝退。mysql-connector-java在2.7.x里用这个坐标到3.x改名为com.mysql:mysql-connector-j这也是很多人升级后踩的第一个坑。2.2 整合MyBatis-Plus与JWT鉴权把配置写对少走弯路依赖加完轮到application.yml。这里配置决定后面能不能少改代码。我会把端口、数据库、MyBatis-Plus、JWT密钥分开写清楚server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/anime_mall?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis-plus: mapper-locations: classpath*:mapper/**/*.xml configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: id-type: auto logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0参数说明serverTimezoneAsia/Shanghai必须加不然MySQL 8时区校验直接报错。map-underscore-to-camel-case: true让数据库的create_time自动映射实体的createTime不用手写一堆resultMap。logic-delete字段是逻辑删除商城系统的订单和商品最好不要物理删不然对账和追溯很难受。log-impl配成StdOutImpl后开发期能在控制台直接看到每条SQL排查数据问题非常管用上线前记得关掉。JWT这块我习惯抽一个JwtUtil类负责生成和解析token再写拦截器统一校验。核心思路是用户登录成功发token前端存localStorage每次请求在Authorization头带上拦截器校验通过后把userId塞进request attribute。一个容易忽略的细节jjwt 0.9.1的parse方法依赖jaxbJDK8以上需要补上jaxb-api依赖不然运行时抛ClassNotFoundException。这属于典型的黑匣子问题不看堆栈根本想不到是缺jar。2.3 商品与订单的API设计接口路径与返回统一格式结构搭好、鉴权通了就该定接口契约。我坚持所有接口返回统一格式前端不用为各种返回各写一套判断。格式是code、message、data三件套200表示成功401表示未登录500表示服务端异常。接口路径按资源命名比如模块路径方法说明商品/api/goods/{id}GET商品详情商品/api/goods/pageGET分页商品列表支持关键字和分类筛选购物车/api/cart/{userId}GET查询用户购物车购物车/api/cart/addPOST加入购物车订单/api/order/createPOST创建订单订单/api/order/{orderNo}GET订单详情支付/api/pay/notifyPOST支付回调这个表前后端各拿一份开发期就可以用Swagger或Apifox去调不用等全部写完。创建订单接口必须走POST它涉及事务和库存操作用GET会在浏览器缓存和日志里留下脏数据。列表接口加分页参数pageNum和pageSize返回结构里带total前端直接渲染分页条。管理端接口和用户端接口都走/api前缀但按模块区分比如/admin/order是管理端查询/api/order/create是用户端下单别混在一起。3. Vue前端与后端联调路由、状态管理与接口对接后端API立起来后前端就是门面。二次元商城的前端有两个特点一是商品图多对图片懒加载有要求二是购物车、订单状态在页面间跳转时需要共享不能每个页面都重新拉接口。这就决定了前端不只是写页面还要把路由、状态管理、接口封装先定好。3.1 Vue项目初始化与路由设计从安装依赖到页面骨架常见做法是用Vue CLI或Vite创建项目。Vite启动快但Vue CLI对新手更友好文档多。如果源码是Vue 2路由就是vue-router 3.x如果是Vue 3就配vue-router 4.x。拿到源码第一件事先看package.json里的vue和vue-router版本版本不匹配是前端跑不起来的头号原因。安装依赖这一步很多人直接npm install然后卡在node-sass或者Python环境上。我的一般做法是删掉package-lock.json再npm install。这种交付型的项目别人拿到源码后最关心的是怎么最快跑起来而不是先读一大段README。装完依赖路由配置放在src/router/index.jsVue 2的写法是import Vue from vue import VueRouter from vue-router Vue.use(VueRouter) const routes [ { path: /, component: () import(/views/Home.vue), meta: { title: 首页 } }, { path: /goods/:id, component: () import(/views/GoodsDetail.vue), meta: { title: 商品详情 } }, { path: /cart, component: () import(/views/Cart.vue), meta: { title: 购物车, requiresAuth: true } }, { path: /order/confirm, component: () import(/views/OrderConfirm.vue), meta: { title: 确认订单, requiresAuth: true } }, { path: /login, component: () import(/views/Login.vue) }, { path: *, redirect: / } ] const router new VueRouter({ mode: history, routes }) router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next(/login) } else { next() } }) export default router这里有几个点要说明。路由懒加载用箭头函数import首页不会把商品详情页的代码一起下下来。requiresAuth是路由元信息配合beforeEach做登录守卫比在每个页面里判断干净得多。mode: history让URL不带#号好看但打包后部署必须让后端或nginx配fallback否则刷新就404这个坑在第5章细说。开发期嫌麻烦就先用默认的hash模式最省心。3.2 Axios封装与接口对接统一处理Token和错误码页面组件里直接fetch不现实几十个接口每个都写一遍错误处理代码会膨胀到没法维护。我习惯在src/utils/request.js里封装axios拦截器统一做三件事带token、处理业务错误码、弹全局消息。import axios from axios import { Message } from element-ui import router from /router const service axios.create({ baseURL: /api, timeout: 10000 }) service.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers[Authorization] token } return config }) service.interceptors.response.use( response { const res response.data if (res.code 200) { return res.data } if (res.code 401) { localStorage.removeItem(token) router.push(/login) } Message.error(res.message || 请求失败) return Promise.reject(new Error(res.message)) }, error { Message.error(error.message || 网络异常) return Promise.reject(error) } ) export default service这段封装的价值在联调阶段体现得最明显。baseURL设成/api开发期由webpack或Vite代理转发到后端8080端口上线后由nginx把/api转发到Java进程前端代码本身不用区分环境。拦截器里return res.data组件里直接拿数据本体不用每处解一层壳。401统一踢回登录页避免每个接口单独判断。3.3 商品列表与购物车的状态管理用Pinia还是Vuex当商品筛选条件、购物车数量、订单确认信息需要在多个组件间共享时就该上状态管理了。Vue 2项目用VuexVue 3项目更推荐Pinia。Pinia删掉了mutations概念逻辑更直观对TypeScript支持更好Vuex在Vue 2里生态成熟网上资料多。选型原则很简单跟着项目里的Vue版本来不要强行跨版本。如果这套源码是Vue 2 Vuex 3硬改成Pinia会引出一堆兼容问题。购物车的核心状态是items数组和totalPrice计算属性变更逻辑集中在add、remove、updateQuantity三个action里配合localStorage持久化页面刷新购物车不丢。这块没有太多玄学主要是把action命名统一别把状态修改散落在各个组件里。3.4 UI组件库与图片懒加载二次元商城的前端性能线二次元商城的商品图动辄上百张首页一次加载十几个商品就可能让页面卡顿。管理端基于Element UI可以很快把表格、弹窗、表单搭出来用户端则要注意图片懒加载。Vue 2下用vue-lazyload插件main.js里注册模板里把img src改成v-lazy。商品详情页的图片数组循环渲染配合过渡动画就有基本可用体验。懒加载的阈值要根据页面布局调不要在用户还没滚动到位置时就加载全部图片。购物车页面的图片尺寸要压缩详情页再用大图同一张图两个size字段别在列表页拖原图。样式这块二次元风格靠CSS变量做主题色切换主色、辅色、价格色各一个变量后续做活动专题页能省不少事。4. 数据库设计与订单链路五张核心表的事务边界商城系统的问题最终都在数据库里暴露。二次元商品比普通商品多了一层复杂性一个商品有普通版、特典版、再版每个版本可能有不同封面图、特典赠品和价格。数据库设计如果在一张表里把这些全塞进去后面改起来就是灾难。4.1 商品SPU与SKU拆分为什么二次元商品不能只用一张表SPU是商品抽象比如“某某手办 1/7比例 普通版”SKU是具体可下单的售卖单元比如“普通版-日版”“特典版-代理版”。电商规范做法是SPU表存商品公共信息SKU表存价格、库存、规格编码。二次元商品尤其需要这样拆一套手办可能有多个版本共享同一套详情图和描述但价格和库存完全不同。核心表我一般这样建CREATE TABLE spu ( id bigint NOT NULL AUTO_INCREMENT, title varchar(128) NOT NULL COMMENT 商品标题, subtitle varchar(255) DEFAULT NULL COMMENT 副标题, main_image varchar(255) NOT NULL COMMENT 主图URL, detail_html text COMMENT 详情页富文本, brand_id bigint DEFAULT NULL COMMENT 品牌ID, category_id bigint DEFAULT NULL COMMENT 分类ID, status tinyint DEFAULT 1 COMMENT 1上架 0下架, deleted tinyint DEFAULT 0 COMMENT 逻辑删除, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品SPU表; CREATE TABLE sku ( id bigint NOT NULL AUTO_INCREMENT, spu_id bigint NOT NULL COMMENT 所属SPU, sku_name varchar(128) NOT NULL COMMENT 如普通版-日版, price decimal(10,2) NOT NULL COMMENT 售价, stock int NOT NULL DEFAULT 0 COMMENT 库存, version int DEFAULT 0 COMMENT 乐观锁版本号, deleted tinyint DEFAULT 0, create_time datetime DEFAULT NULL, update_time datetime DEFAULT NULL, PRIMARY KEY (id), KEY idx_spu_id (spu_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT商品SKU表;字符集用utf8mb4而不是utf8因为二次元商品标题里经常有emoji和特殊符号utf8mb4才存得下。detail_html用text类型详情页富文本图片多大字段单独放不拖慢列表查询。deleted字段配合MyBatis-Plus逻辑删除管理端删错商品还能有后悔药这是电商运营的刚需。4.2 订单状态机与库存扣减并发场景下怎么保证不超卖订单表承载了整条链路。订单号建议用业务单号不用自增id格式带日期和随机数比如20250607153000123456对账和查单都方便。订单扣库存是并发问题高发区。两个用户同时买最后一个手办如果先查库存再更新必然有一个请求读到旧值导致超卖。解决办法是更新时加库存条件影响行数为0就当失败UPDATE sku SET stock stock - 1, version version 1 WHERE id #{skuId} AND stock 0;这条SQL对应的Java逻辑要包在事务里先扣库存再创建订单任何一步失败整体回滚。MyBatis-Plus自带乐观锁插件但直接用这条条件更新SQL反而更直观。注意事务边界减库存、生成订单、清购物车三个操作必须在同一个事务方法里不要拆成三个接口在前端依次调用否则中间任何一个失败数据就悬空了。订单状态建议用tinyint存0待支付、1已支付、2已发货、3已完成、4已取消状态流转写在一个枚举类里不要散落到处是魔法数字。4.3 数据库增删改查与结构变更开发期怎么管理SQL脚本拿到数据库文件第一件事是用source命令导入然后花十分钟做数据库增删改查的基础验证查一遍SPU、SKU、订单表的关联关系是否完整商品数据能不能查到库存和订单对得上。开发期的表结构会频繁调整。我见过最痛心的做法是在Navicat里手改表然后代码和数据库对不上只能靠肉眼排查。建议所有结构变更写成增量SQL脚本按日期编号放在sql目录下-- 20250607_init.sql CREATE DATABASE IF NOT EXISTS anime_mall DEFAULT CHARACTER SET utf8mb4; USE anime_mall; -- 其余建表语句…… -- 20250608_alter_sku.sql ALTER TABLE sku ADD COLUMN origin_price decimal(10,2) DEFAULT NULL COMMENT 原价 AFTER price; ALTER TABLE sku MODIFY COLUMN sku_name varchar(256) NOT NULL COMMENT SKU名称支持加长标题;脚本式管理结构变更的好处是换机器、换人、回滚都能追溯。配合Flyway可以启动自动执行但对这种直接给源码和数据库文件的交付项目手动脚本加文档说明已经足够。记住数据库脚本和代码一样需要版本管理别让Navicat的导出文件成为唯一真相。5. 二次元商城开发避坑图片、跨域、打包与支付下面这些是实战里淌出来的。五类问题按出现频率排序每个都是真实翻车点。5.1 商品图片加载失败与防盗链问题现象商品列表图在本地好好的部署到服务器后大量裂图控制台报403或混合内容错误。原因二次元商品图经常从画师或合作方站点引用很多站点了防盗链检查Referer非白名单域名一律拒绝。部署后域名变了引用自然失效。另外如果站点是https资源是http浏览器直接拦截。解决商品图必须全部落到自己的存储。开发期本地目录加nginx映射上线后统一走对象存储。数据库里存相对路径而不是完整URL比如/goods/2025/06/07/xxx.jpg由部署环境拼接域名这样从http切https不需要改库。还有一个小坑图片文件名不要用中文和空格部分旧版nginx对中文URL编码处理不一致会随机404。5.2 前后端联调时的跨域配置现象前端npm run dev端口是3000后端8080浏览器直接请求接口报“Access-Control-Allow-Origin”错误。原因浏览器同源策略前后端端口不同就触发跨域。解决开发期最省事的做法是在Vue的vue.config.js里配proxy而不是在后端开CORS放行module.exports { devServer: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } } }生产环境用nginx反代同源后端开CORS反而放开一个安全面没必要。如果坚持后端开CORS要注意预检请求OPTIONSSpringBoot要配allowedOriginPatterns而不是allowedOrigins后者在带凭证的请求下会报错。这个区别很隐蔽界面上一模一样的配置一个能跑一个不能跑。5.3 库存超卖与重复下单现象活动价手办上线秒空但后台订单数比初始库存多或者用户双击提交按钮生成了两笔相同订单。原因库存扣减没有条件判断下单接口没有做重复提交处理。解决库存问题按4.2的update语句解决。重复下单一般两个手段前端按钮提交后立刻disabled后端对同一用户同一SKU在一定时间窗口内做幂等校验常见做法是前端生成requestId后端用Redis存已处理请求——没有Redis就用数据库唯一索引兜底。别小看这个支付系统回调和用户手滑都会把重复订单问题放大。我发现很多人在测试环境测不出这个问题是因为测试工具不会模拟双击建议用脚本对下单接口压一发很快就能暴露。5.4 vue打包放进SpringBoot后路由刷新404现象npm run build之后把dist目录放进SpringBoot的static目录从首页点进商品详情没问题一刷新页面就是404。原因前端是history路由模式URL路径对后端来说不存在对应静态文件SpringBoot默认找不到资源就返回404。解决两种做法。第一种最简单路由改回hash模式URL带#不用后端做任何配置。第二种是后端实现一个转发兜底把不带点后缀的路径统一转发到index.htmlController public class SpaController { RequestMapping(value /{path:[^\\.]*}, method RequestMethod.GET) public String forwardSingle() { return forward:/index.html; } }这段配置只处理单层路径像/admin/dashboard这种多级路径还需要再加一层/**的映射正则写起来很啰嗦。所以我的推荐是彻底用nginx托管前端静态文件只在nginx层做fallbackSpringBoot专心做API。前后端彻底分家更新前端不用重新打后端jar包这才是vue放进springboot最省心的姿势。5.5 支付回调的幂等处理现象支付平台侧回调连发三次每次都更新订单状态、加积分用户支付一次被加三次积分。原因支付回调大部分是支付平台的异步通知可能多次到达后端必须先判断订单当前状态再处理。解决回调处理函数开头加状态校验如果订单已经是“已支付”直接返回成功标记给支付平台不重复执行业务逻辑。同时支付回调业务用try-catch包住捕获异常时记录日志并返回失败让平台重试但一定不能重试幂等消费的部分。用沙箱环境把回调重发、延迟回调、重复回调三种情况都测一遍再上线。测试环境还要注意回调地址必须是公网能访问的很多人卡在这步不是代码问题而是本地ngrok没配好回调根本到不了后端。6. 从源码到可演示最小启动命令与三个验证点6.1 先跑通再读文档最小启动顺序与三个验证点拿到这份源码、数据库和文档按这个顺序跑别跳步用Navicat或命令行source命令导入sql文件确认anime_mall库建好SPU、SKU、订单表里都有数据。改application.yml里的数据库账号密码先别动其他配置。后端目录执行mvn spring-boot:run看到Tomcat started on port 8080就算起来了。前端目录npm install、npm run dev浏览器打开本地地址。跑起来后验证三个关键点就说明链路是通的验证点方法期望结果登录鉴权用管理端账号登录看Network里请求是否带Authorization头登录成功访问受保护接口返回200商品链路列表页点商品进详情加购物车再结算库存减少1购物车数量正确支付回调用沙箱支付后触发回调观察后端日志订单状态变为已支付且只更新一次我个人的习惯是这三步跑通后再去读文档里的接口说明比从头读文档快得多。运行期遇到端口占用、数据库连接失败先看堆栈前五行八成是配置问题而不是代码问题。端口冲突时用lsof -i:8080找占用进程数据库连不上就先telnet 3306不要一上来就怀疑代码。最后说一句血泪经验不要因为急着演示而跳过支付回调的幂等验证。我遇到过最尴尬的一次就是演示下单时支付回调重试导致订单状态反复跳当场翻车。把启动和验证流程按上面这套固化下来后面加功能、改需求都稳。希望帮到你。本文还有配套的精品资源点击获取