SpringBoot+Layui+Vue动漫商城系统设计与部署实战

做这套系统的时候我一直在想一个问题为什么一套动漫商城管理系统标题里会同时出现 Layui 和 Vue 两个前端框架不少同行看到这里第一反应是“是不是写错了”但真正在企业里做过完整项目的人都知道这种组合太常见了——管理后台用 Layui 保开发效率用户商城用 Vue 保交互体验后端统一走 SpringBoot MyBatis MySQL一套数据模型支撑两端业务。这套东西从头到尾跑通后我整理了下整个设计和实现过程包括为什么这么选型、表结构怎么设计、MyBatis 的细节怎么处理、两套前端怎么配合后端工作以及最后部署上线的坑。这篇内容适合刚接触企业级管理系统开发的读者也适合准备用 SpringBoot 做商城类项目的团队参考全程讲实际落地不聊虚的。1. 为什么这套系统会把 Layui 和 Vue 放在一起而不是二选一很多技术文章一上来就告诉你“用 Vue 做后台用 Vue 做商城全部统一”听起来很完美但放到真实的企业项目里尤其是要快速上线一套管理系统的时候Layui 的价值反而比想象中大。这个项目同时包含两个差异极大的前端场景一边是给运营和客服用的管理后台页面上全是表格、表单、弹窗、树形菜单追求的是“打开就能用、操作不出错”另一边是给用户看的动漫商城需要商品列表、详情页、购物车、下单流程对页面渲染效率、状态管理、路由跳转都有更高要求。这两边的诉求完全不同硬塞进同一个框架里只会让开发和维护都别扭。1.1 管理后台选 Layui 的真实原因Layui 严格来说是“经典模块化前端框架”它最大的特点是不需要 Node 环境、不需要构建打包直接引入 CSS 和 JS 文件就能工作页面里的表格、分页、表单校验、日期选择、弹层这些后台高频组件全部内置。对后端工程师来说这套东西几乎是零学习成本——写完接口在 HTML 里调一下 table 组件的 url 属性数据就自动渲染成表格了连拼接 DOM 的代码都不用写。我选择 Layui 做管理后台还有一个细节这个项目的管理端有大量“查询 列表 编辑 审核”的操作这类页面用不上 Vue 的响应式优势反而 Layui 的自动渲染逻辑更省事。你不需要维护一堆 data 和 method只需要按它的数据格式返回 JSON组件自己会处理翻页、排序、行内操作。对企业项目来说这种“所见即所得”的开发方式可以把后台功能的开发周期压缩一半以上。1.2 商城侧为什么必须上 Vue用户商城是完全不同的场景。商品列表要按分类筛选、按价格排序详情页要切换规格、实时计算价格购物车要维护一套本地状态结算页要校验多级表单——这些交互用传统的 jQuery 写法也能做但代码会很快膨胀到难以维护。Vue 的数据驱动和组件化机制天然适合解决这类问题。比如商城首页的“今日上新”和“人气榜单”两个模块数据结构不同、渲染样式不同但都需要从后端拉数据并响应筛选操作。用 Vue 写就是两个独立组件各自管理自己的数据请求和展示逻辑购物车更明显加入商品、修改数量、计算合计、删除商品全都是对 state 的变更Vuex 或者 Pinia 可以很干净地把这些状态集中管理。再加上 Vue Router 做页面跳转整个商城前端的代码结构会比传统写法清晰好几个量级。1.3 混用架构的边界什么时候该拆什么时候该统这套系统混用两个前端框架不是因为技术洁癖不够而是因为“管理后台”和“用户商城”本来就是两个独立的应用它们只是共享同一套后端接口。在项目里这两套代码也做了物理隔离——后台页面单独一个目录商城前端单独一个工程互不引用。但这里有个边界要拎清楚如果项目里所有页面都要做复杂的状态联动、跨页面数据共享比如电商运营后台的订单流水大屏、实时数据看板那还是老老实实用 Vue 做全套Layui 适合的是“标准 CRUD 常规表单”的管理页面类型。团队如果在项目初期不确定未来扩展方向我更建议把核心业务模块做成 Vue边缘的管理模块用 Layui这样可以控制住开发成本又不至于让核心技术栈失控。2. 动漫商城的数据表设计虚拟商品和实物商品并存怎么建模动漫商城有个很典型的特点商品形态多样既有虚拟的精品漫画、番剧、壁纸资源又有实体的手办、周边、服饰。这张商品表如果设计得不好后面订单、库存、支付全都会跟着出问题。这个项目的数据库设计我分了几个核心维度来讲每一张表都经过了几轮实际业务验证。2.1 商品模型SPU 与 SKU 分离多形态并存我采用的是电商系统里通用的 SPU/SKU 模型。SPUStandard Product Unit是商品聚合层比如“某热门漫画第一季完整版”这是用户看到的商品主体SKUStock Keeping Unit是具体的售卖单元比如“该漫画的电子版”“该漫画的实体设定集”“该漫画实体版电子版捆绑包”。一张 SPU 对应多个 SKU但每个 SKU 的售价、库存、规格参数都要独立维护。商品表的核心字段大致这样设计CREATE TABLE spu ( id BIGINT PRIMARY KEY AUTO_INCREMENT, category_id BIGINT NOT NULL COMMENT 分类id, title VARCHAR(200) NOT NULL COMMENT 商品标题, subtitle VARCHAR(500) COMMENT 副标题/卖点, cover_img VARCHAR(500) COMMENT 封面图, detail_html MEDIUMTEXT COMMENT 详情页富文本, status TINYINT DEFAULT 1 COMMENT 1上架 0下架 2审核中, goods_type TINYINT COMMENT 1虚拟 2实物 3虚拟实物, create_time DATETIME DEFAULT CURRENT_TIMESTAMP );goods_type 这个字段是专门为动漫商城加的——虚拟商品和实物商品在发货逻辑上完全不同虚拟商品下单后直接发卡密或开放在线观看权限而实物商品要走物流发货。这个字段会让后面的订单处理逻辑分叉设计时一定不能省。SKU 表里我额外加了两个比较关键的字段一个是virtual_stock虚拟库存处理“同一个商品既有实体库存又有兑换码库存”的情况另一个是digital_file_url用于存放虚拟商品的资源地址或卡密池关联 ID。这样下单时一个 SKU 既能走库存扣减也能走资源解锁逻辑非常清晰。2.2 订单与库存预占、释放、快照一个都不能少订单表的设计是这个项目里踩坑最多的部分。最开始我按常规电商的订单表设计只存了 user_id、total_amount、status 这些基础字段结果上线后发现运营经常截图为“用户当时下单的商品名称和价格”做售后可商品早就改名或改价了全乱套。所以订单表里必须有商品快照字段。实际操作中订单主表和订单明细表的设计是这套系统的骨架。订单主表存支付流水、收货信息、订单状态订单明细表则存死每个 SKU 的商品名、单价、数量、商品图。明细表里直接冗余商品的标题和图片路径而不是下单时再去关联 SPU 表查——这样即使后台改了商品名称或价格订单历史依然完整可追溯。下单流程里的库存处理我采用了“预占 定时释放”的策略用户提交订单但未支付时锁定对应 SKU 的库存支付超时再释放。释放逻辑写在定时任务里每 15 分钟扫描一次超时未支付的订单把预占库存加回。这一步如果做成“拍下就扣库存”会被用户恶意下单把库存占光如果做成“支付后再扣库存”大促时又容易超卖。预占机制是目前最稳妥的折中。2.3 RBAC 权限模型与操作日志的数据落地企业级管理系统必须解决“谁能干什么”的问题。我用了标准的 RBAC 模型用户表、角色表、权限表、用户角色关联表、角色权限关联表五张表闭环。实际业务里运营组的角色能管理商品上下架、处理订单备注但不能改支付配置财务角色能看全部订单金额统计但不能编辑商品信息。这套模型的 SQL 简单表达就是按用户的角色编码去关联菜单权限后端在拦截器里校验接口的 requiredPerm 注解即可。操作日志也是被很多人忽略的重头戏。管理系统里商品的上下架、改价、优惠券发放都需要留痕。我开发了一个基于 Spring 的事件监听器实现的操作日志模块通过 AOP 切面自动记录操作人、操作时间、操作详情、IP 地址这里不依赖硬编码的 SQL 语句而是单独建了一张 operation_log 表配合 Spring Security 和 JWT 的会话信息把“谁在什么时候改了什么东西”完整存下来。遇到运营误操作拉出日志一分钟就能定位责任人。3. SpringBoot 服务端分层与 MyBatis 持久层的实战细节说完了表结构再看后端代码怎么组织。这套系统的后端沿用 SpringBoot 标准三层架构Controller 层负责接收参数和返回结果Service 层做业务逻辑Mapper 层访问数据库。很多初学者会直接把业务逻辑写在 Controller 里图省事但后面系统一复杂这种代码根本没法维护。所以这个项目从第一天起就严格要求分层我的具体做法如下。3.1 Controller 只管参数与响应业务全下沉到 ServiceController 层的职责只有一个把 HTTP 请求的 JSON 参数绑定成对象调用 Service 方法再把返回结果统一包装成 Result 对象返回。比如商品列表接口RestController RequestMapping(/api/goods) public class GoodsController { Resource private GoodsService goodsService; GetMapping(/list) public Result page(GoodsQuery query) { return Result.success(goodsService.page(query)); } }Service 层处理所有业务规则参数校验、权限校验、数据组装、事务控制。这里有一个我的习惯Service 层一定要基于接口编程先定义接口再写实现类因为在项目后期加缓存、加多数据源、做性能监控都靠这一层做扩展点。另一个很容易犯的错是在 Service 里直接操作 HttpSession 或 HttpServletRequest。看起来方便但整套单元测试直接没法写——方法里动不动就依赖 Servlet 容器。正确的做法是需要用户信息的接口把 userId 作为参数从 Controller 传入或者从自定义的 UserContext基于 ThreadLocal 实现取。我们这套管理系统里就用 UserContext 从 JWT 解析出当前用户在 Service 层里可以直接读取也不污染接口签名。3.2 Mapper 层的动态 SQL复杂条件查询的命门管理后台最多的需求就是各种“组合条件查询”按商品分类、价格区间、上下架状态、创建时间范围任意勾选组合筛选。如果给每一种组合都写一个固定的 SQL那工程量是组合爆炸的。MyBatis 的动态 SQL 就是用来解决这个问题的。我在商品查询的 Mapper XML 里用了where配合if标签select idselectGoodsPage resultTypecom.demo.entity.Goods SELECT * FROM spu where if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (title LIKE CONCAT(%, #{keyword}, %) OR subtitle LIKE CONCAT(%, #{keyword}, %)) /if if teststatus ! null AND status #{status} /if if teststartTime ! null AND create_time gt; #{startTime} /if /where ORDER BY create_time DESC /select这套写法的好处是 MyBatis 会智能处理 where 子句里第一个条件前面的 AND不会出现“WHERE AND”这种语法错误。另外有个容易被坑的点条件里如果要用符号在 XML 里必须写成lt;否则 XML 解析直接报错。我第一次写的时候就被这个坑过排查了半天。关于 Mapper 层的实现方式这个项目是“XML 注解”混用。简单 SQL单表增删改查用注解比如Select(SELECT * FROM spu WHERE id #{id})复杂 SQL多表联查、动态条件一律用 XML。为什么这么分因为复杂 SQL 写进注解字符串里可读性太差而且不便于在 XML 里格式化简单 SQL 用注解能少写一个 XML 文件代码更紧凑。3.3 分页插件、缓存与事务三个最容易出事故的点分页我选用的是 PageHelper也兼容 MyBatis-Plus 的分页插件思路。PageHelper 的用法很简单查询前调用PageHelper.startPage(pageNum, pageSize)紧接着的查询就是分页查询然后用PageInfo包装返回数据。这里有两件事一定要注意第一startPage只能作用于接下来的第一条 SQL。如果你在它之后先做了别的查询或者赋值操作分页就会作用到错误的地方去。第二PageHelper 本质是拦截器改写 SQL自动化帮你在原 SQL 后面拼 LIMIT 或 ROW_NUM所以不能在已有LIMIT的 SQL 上再用分页会直接报错。缓存我用了两层。第一层是 Caffeine 本地缓存用来缓存商品分类、系统配置这类变化极少的热点数据第二层是 Redis 缓存用来缓存商城首页的推荐位数据和商品详情。缓存的坑在于“更新策略”分类修改了怎么保证缓存也变我采用的是 Cache Aside 模式——先更新数据库再删除缓存下一次读取时自然回填。写操作不直接更新缓存而是删掉它等“读”来重建这样做可以避免并发写时把脏数据写进缓存。事务控制上默认的 Transactional 只处理 RuntimeException 回滚。如果你在 Service 里抛出的是受检异常比如throws Exception事务是不回滚的。解决办法有两种要么自定义业务异常让它继承 RuntimeException要么在 Transactional 注解上显式标注rollbackFor Exception.class。我们项目里统一用前者让所有业务异常都继承一个 BizException 基类理由很简单你不会希望每写一个 Service 方法都要考虑异常类型。4. Layui 管理后台与 Vue 商城的落地细节后台和商城两套前端虽然技术栈不同但都要和后端讲同一套“接口规矩”。这章我把两边怎么落地的细节拆开讲包括前端如何调用后端接口、如何处理登录状态、如何保证数据格式双方都认。4.1 后端如何配合 Layui 的 table 组件Layui 的表格组件有自己固定的数据格式要求。后端返回的 JSON 必须包含 code、msg、count、data 四个字段其中 code 必须等于 0 才表示成功count 是数据总量data 是当前页的数据列表。我在后端封装了专门的PageResult对象public class LayuiTableResult { private Integer code 0; private String msg ; private Long count; private List? data; }所有分页接口都返回这个结构Layui 的 table 组件拿到后直接渲染连一行 JS 都不用写。table.render({ url: /api/goods/list, elem: #goodsTable, page: true })就完成了“请求接口 渲染列表 分页”三个动作。这里有个细节Layui 默认把分页参数命名为page和limit所以你后端的分页接口参数命名最好也保持一致避免前端每次去做参数转换和映射。如果你在 SpringBoot 里接收参数时用了PageQuery对象字段命名就用 page 和 limit不用 PageNum 和 PageSize这样可以减少很多硬编码上的来回调试。后台页面的表单提交我统一用ajax提交 JSON然后在 on.success 回调里判断 code再决定是刷新表格还是弹出错误提示。弹窗用 layer.confirm提示用 layer.msg这些组件都是 Layui 内置的基本不用引入额外依赖。对后端转前端的人而言这套东西真正做到了打开即用。4.2 Vue 商城的 API 封装与登录态处理商城前端是 Vue 工程使用 Vue CLI 搭建配置了 axios 做 HTTP 请求。我做的第一件事就是把 axios 实例统一封装baseURL 指向/api然后设置请求拦截器和响应拦截器。请求拦截器里做的事是每次请求前从 localStorage 读取 token加在 Authorization 请求头上。响应拦截器里做的事是统一处理业务错误和登录失效——当后端返回 code 表示未登录时比如 401全局提示“登录已过期”清除本地登录状态然后跳转到登录页。这个逻辑写在拦截器里商城里任何组件都不用各自处理登录失效问题。关于路由权限Vue Router 里我用了全局前置守卫beforeEach根据 meta 里标记的requiresAuth判断页面是否需要登录购物车、订单列表、个人中心都标记为需要登录商品列表和详情页放行。这种实现虽然简单但胜在直观可维护。如果后期要做“管理员从商城入口直接进后台”只需要再加一层角色判断在路由守卫里检查用户角色的权限码就行。4.3 跨域、Cookie 与登录态混用架构里的隐形地雷两套前端共享同一套后端 API最容易爆的问题就是跨域。Layui 后台是传统的 CookieSession 方案前后端部署在同一域名下基本没跨域问题Vue 商城做前后端分离本地开发时跑在 localhost:8080接口跑在 localhost:8081跨域马上出现。解决跨域我在开发环境用的方式是 Vue CLI 的 devServer 代理——把/api前缀的请求代理到后端的 8081 端口前端代码里仍然写相对路径。生产环境则用 Nginx 反向代理把/api转发到后端的 jar 服务。这样做的好处是整个项目所有请求都用相对 URL不写死域名换环境部署不用改代码。登录态就更微妙了。Layui 后台靠 Session 保持登录Vue 商城靠 TokenJWT保持登录但两套业务共用同一个用户体系。实际操作是后台登录走 Session商城登录走 JWT两套各归各的互不干扰。如果将来要把“用户登录后一键跳到后台”打通可以用 JWT 作为主登录凭证SSO 单点登录再去统一整合。现在这套管理系统的权限入口已经做了双通道处理实际用下来没有特别复杂的问题。5. 完整项目从源码跑通到部署的避坑实录这套系统网上有完整版源码很多同学下载后第一件事就是本地跑但跑通的人少半。不是源码有问题而是环境和顺序不对。这一章我把从本地运行到服务器部署的完整链路梳理一遍包括环境准备、初始化顺序和最容易出错的几个地方。5.1 本地跑通项目的正确顺序第一步肯定是装环境。JDK 1.8、Maven 3.6、MySQL 5.7 或者 8.0、Node 14版本尽量对齐项目的 pom.xml 和 package.json 里声明的版本。有个坑是项目用的是 MySQL 8 的话pom.xml里的驱动版本必须是mysql-connector-java8.x驱动类名也要从com.mysql.jdbc.Driver改成com.mysql.cj.jdbc.Driver如果用 5.x 驱动连 8.x 数据库控制台会持续输出警告甚至认证失败。第二步是初始化数据库。源码里一般有sql目录里面有建库脚本和初始数据脚本。执行顺序很重要先建库再执行建表脚本最后执行初始化数据脚本。不要直接在命令行里一个一个半手动复制执行我用的是 Navicat 整体运行 SQL 文件保证脚本里表之间的依赖关系按顺序执行。第三步是修改后端配置文件里的数据库连接。你要把jdbc:mysql://localhost:3306/xxx这段里的库名、账号、密码改成自己本机的。如果不改启动 SpringBoot 会直接报无法连接数据库很多人卡在这步还不知道为什么。第四步是启动后端观察控制台日志。看到 “Started Application in x.x seconds” 才算成功。如果端口被占用在application.yml里改 server.port 就行。第五步是启动 Vue 商城前端。在商城目录执行npm install装依赖然后npm run serveVue CLI 会打印一个本地访问地址。Layui 后台因为是静态资源方式如果被放在 SpringBoot 的resources/static下直接访问后端的端口加路径就可以打开这一步也是新手容易忽略的——后台页面认不到先检查静态资源路径是否正确。5.2 服务器部署的五步操作本地跑通之后部署到服务器就是另一回事了。我用的部署方案是后端打成 jar 包前台 Vue 工程构建成静态文件交由 Nginx 托管Layui 后台直接放进 Nginx 静态目录MySQL 单独部署整体结构如下。后端打包在项目根目录执行mvn clean package -DskipTests。打包完成后 target 目录下会生成一个可执行的 jar 文件。注意如果你的项目里配置了多环境 profile打包时要指定-Dspring.profiles.activeprod这样打包出来的 jar 会带上生产环境的配置。Vue 前端构建在商城工程目录执行npm run build会生成一个dist目录里面是纯静态文件。这个 dist 的路径和baseURL需要检查一下如果接口请求是相对路径/api那构建出来的 JS 里请求就是/api开头Nginx 配置里把/api转发到后端接口即可。Nginx 配置核心段落server { listen 80; server_name your-domain.com; location / { root /var/www/shop-web; index index.html; try_files $uri $uri/ /index.html; } location /admin/ { alias /var/www/admin-pages/; index index.html; } location /api/ { proxy_pass http://127.0.0.1:8081/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }proxy_pass这里有一个细节如果写proxy_pass http://127.0.0.1:8081/api/Nginx 会保留/api前缀转发如果写http://127.0.0.1:8081/就不保留前缀。这个必须根据后端接口的实际实际路径来定我这边后端接口都带/api前缀所以选择了保留前缀的方式。最后用java -jar xxx.jar启动后端再用systemctl或者pm2守护进程。如果进程挂了能自动拉起管理后台和商城基本就稳定运作了。5.3 我踩过的三个部署坑第一个坑是 MySQL 8 的认证插件问题。默认安装在 Linux 上的 MySQL 8 创建用户时认证插件是caching_sha2_password但项目里用的连接池驱动如果是 5.x 版本根本认不了这种新认证方式。解决办法是创建用户时指定mysql_native_password或者直接用 8.x 驱动和 8.x 版本的 JDBC 连接字符两个方向都能解决我更推荐后者因为不用改 MySQL 用户的密码规则。第二个坑是时区问题。MySQL 连接串如果不带serverTimezoneAsia/Shanghai同时服务器系统时区是 UTC那查询出来的时间跟本地时间会差 8 个小时订单创建时间全乱了。后来我统一在 jdbc-url 里配置了时区参数顺带在 MySQL 初始化时把 time_zone 设置成了 8:00两个位置都改到位时间相关的问题一次解决。第三个坑是 Vue 刷新页面后 404。这其实是前端路由的 history 模式造成的浏览器直接访问/goods/detail/123这个路径Nginx 会去磁盘找对应的文件找不到就 404。办法就是 Nginx 配置里的try_files $uri $uri/ /index.html所有找不到的路径全部退回首页由 Vue Router 自己接管路由渲染。我见过的不少线上商城刷新页面白屏基本都是这行配置漏了。最后分享两个我在实际维护中沉淀下来的小技巧第一个是关于接口返回格式的。不管 Layui 后台还是 Vue 商城我都强制后端所有接口统一返回{ code, msg, data }结构前端只认这一种格式。很多项目做久了会出现“有的接口直接返回 data、有的接口返回整个对象”的混乱局面新同事接手的第一个月全在猜接口返回结构浪费时间。提前定死规范这套系统后期加人维护特别省心。第二个是关于改完接口之后怎么验证。我习惯的做法是后端代码改完先用curl直接请求接口看返回的 JSON 是否符合预期然后再去前端页面上操作看数据有没有正常渲染。很多同事改完后端直接刷新浏览器页面数据没变就开始怀疑前端缓存、怀疑浏览器代理、怀疑 Nginx其实大概率是后端代码没生效。先用命令行探测接口能帮你把排查问题的范围缩小一半以上。这套动漫商城管理系统整体做下来最大的体会是技术选型没有绝对的好坏Layui 和 Vue 放在一起也并不是什么“技术混搭耻辱”关键是你要清楚每一块代码解决什么问题然后把接口规范、数据结构和权限边界定清楚。希望这篇整理能帮到正在做同类系统的你少走几个我走过的弯路。