这两年我前前后后帮朋友折腾过好几套销售管理系统，说实话，市面上的代码不少，但能称得上“结构完整、开箱即用”的不算多。最近拿到这套雪具销售系统信息管理系统源码-SpringBoot后端+Vue前端+MySQL，我完整跑了一遍，第一感觉就是：这项目该有的东西都有，业务闭环也清楚，最关键的是真的能直接运行，不是那种缺依赖、少表、一启动就报错的半成品。这篇文章我就从项目拆解、技术选型、源码结构、数据库设计、启动流程、踩坑记录到二次改造方向，全流程讲一遍。如果你正在做Java Web相关的课程设计、毕业设计，或者自己经营滑雪用品门店想上一套轻量管理后台，这篇内容能帮你省掉不少弯路。

先从大方向聊。很多人拿到一套比如SpringBoot+Vue+MySQL的源码，第一反应是赶紧把环境配好、让页面跑起来。这个想法没错，但如果只是“能跑”，那你学到的东西其实很有限。真正有价值的是搞清楚：这套系统为什么这么设计？表为什么拆成这个结构？一个请求从前端点按钮到数据库落地，中间经过哪些代码？把这些吃透了，哪怕明天让你换一个业务场景，比如改成羽毛球用品、户外装备、甚至餐饮进销存，你也能很快迁移过去。所以下面我会先把业务和技术逻辑讲透，再带你一步步跑起来。

1. 这套雪具销售系统解决的是门店最头疼的几件事

1.1 滑雪用品门店的真实管理痛点

雪具店和普通服装店、数码店有个明显的区别——商品属性复杂。滑雪板有长度规格、硬度参数，雪鞋有欧码和mondo码之分，固定器有 DIN 值范围，雪镜还要区分柱面镜和球面镜。同样的一个品牌，可能拆出几百个SKU。如果用Excel管理，光是库存更新就能让人崩溃，更别说订单、会员、积分这些数据了。我当时帮朋友梳理需求的时候，他列了三个最头疼的痛点：第一是库存对不上，卖出去一双雪鞋忘了登记，月底盘点的时候台账和实物差一大截；第二是会员积分全靠手工记账，雪季结束想给老客户发优惠，Excel里根本拉不出准确名单；第三是老板想看哪个型号卖得好，只能靠“感觉”，没有数据支撑。

1.2 这套系统覆盖的核心业务边界

这套系统对应解决的，就是上面这些典型问题。从标题能看出它是一个信息管理系统，按我的使用经验，核心模块大致集中在四块：

• 商品管理：维护雪具分类、品牌、型号、尺码、价格、库存量，支持上下架操作。这是所有业务的地基，商品资料不干净，后面的订单、统计都会跟着乱。
• 订单管理：客户下单、订单列表查询、订单状态流转（待付款、已付款、已发货、已完成、已取消）。雪具单价高，一个订单可能同时包含雪板、固定器、雪鞋，所以订单明细必须支持多商品。
• 会员管理：记录客户基本信息、联系方式、会员等级、积分余额。雪具行业复购周期长，但老客户转介绍率极高，会员体系直接影响淡季的促销转化。
• 数据统计看板：销售总额、订单数量、商品销量排行、库存预警。对门店主来说，这个模块比前面几个都“值钱”，因为它直接辅助进货决策——哪个型号卖得好，哪个积压了，一眼就能看出来。

1.3 什么类型的人最适合拿它当参考

我个人的判断是，这套系统至少有三类人值得仔细研究。第一类是做Java Web课程设计或毕业设计的在校生。它麻雀虽小五脏俱全，Controller、Service、Mapper分层清楚，前端Vue组件化，写论文时不管是画架构图还是讲业务流程，都有现成的素材。第二类是中小型体育用品门店的技术负责人或店主，在这个基础上做二次开发，比从零造轮子省太多时间。第三类是刚学完SpringBoot和Vue、想找项目练手的前端或后端新人。这个项目的代码量不算大，适合通读，你能在一两天里把一个完整前后端分离项目的请求链路、数据建模思路理顺。

2. 为什么这个项目选SpringBoot+Vue+MySQL而不是其他方案

2.1 SpringBoot在Java后端生态里的地位

如果你去搜springboot框架介绍，一定会看到“约定优于配置”“内嵌Tomcat”“起步依赖”这几个关键词。它之所以成为现在Java后端项目的主流，核心在于它大幅降低了整合成本。假设用传统SSM（Spring+SpringMVC+MyBatis）搭一个项目，你得自己配置web.xml、Spring配置文件、事务管理器、连接池，稍不注意版本冲突就半天起步。SpringBoot把这些都收了，你只需要在pom.xml里引入web、mybatis、mysql驱动几个starter，再写一个application.yml，就能跑起来一个接口服务。这套雪具系统选用它，本质上选的是开发效率和生态兼容性。

2.2 Vue前端在管理后台场景下的优势

管理后台这种页面，特点是表单多、表格多、数据联动多。传统JSP或Thymeleaf服务端渲染不是不能做，但只要涉及局部刷新，就要写大量JS和Ajax回调，代码维护成本很高。Vue的核心优势是数据驱动视图——你只需要维护一个数据对象，数据变了页面自动变，不需要手动操作DOM。再加上现在前后端分离已经成为主流，后端专心出接口，前端专心做交互，两者通过JSON打交道，团队协作和后续扩展都清爽很多。这套系统选Vue做前端，从页面结构看也是典型的组件化写法，列表页、表单页、弹窗都拆成了独立组件。

2.3 MySQL的地位与边界

MySQL在这个组合里承担的是数据持久化角色。和Oracle、SQL Server相比，MySQL开源免费，部署轻量，对于日订单量几千笔以内的小中型业务系统，性能和稳定性完全足够。雪具销售系统属于典型的OLTP场景，表结构以增删改查为主，查询维度也就是按时间、按状态、按商品名称，MySQL加几个普通索引就够了。有人会问，要不要上Redis做缓存？我的建议是：前期没必要。商品和订单的数据量没到那个程度，接口查询即便走全表扫描也就几十毫秒，先保证逻辑正确，等并发压力真的上来了再加缓存也不迟。过度设计是新手项目最常见的毛病之一。

2.4 关于“把SpringBoot jar反编译成项目”这个想法的提醒

有很多人拿到一个SpringBoot项目的jar包，想通过反编译还原出工程源码。这个思路可以理解，但我不建议作为首选。反编译工具（比如JD-GUI、CFR）确实能把class文件还原成Java代码，但反编译出来的代码丢失了注释、常量命名可能被重排、配置文件里的敏感信息也可能缺漏，数据库脚本和前端资源更是不可能从jar里完整拿回来。更现实的做法是：直接找一套开源或分享出来的源码项目，像这套雪具系统就带了完整的后端工程、前端工程和SQL脚本，这才是“可直接运行”的意义所在。源码的价值在于你能改，能扩展，能理解设计者当时的思路，而不是只能当黑盒跑一下。

3. 翻开源码：从后端Java到前端Vue页面的一次完整请求链路

3.1 后端工程结构：一眼定位代码位置

拿到源码之后，先别急着启动，花十分钟把目录结构过一遍比什么都重要。这套系统的后端是标准的Maven工程，包结构大概是这样的：

src/main/java ├── com.snow.sales │ ├── SalesApplication.java # SpringBoot启动类 │ ├── controller # 控制层，接收前端请求 │ │ ├── ProductController.java │ │ ├── OrderController.java │ │ ├── CustomerController.java │ │ └── UserController.java │ ├── service # 业务逻辑层 │ │ ├── ProductService.java │ │ ├── OrderService.java │ │ └── ... │ ├── mapper # MyBatis数据访问层 │ │ ├── ProductMapper.java │ │ ├── OrderMapper.java │ │ └── ... │ ├── entity # 数据库实体类 │ ├── common # 公共封装，比如统一返回Result │ └── config # 配置类，跨域、拦截器、MyBatis └── src/main/resources ├── application.yml # 核心配置文件 └── mapper # MyBatis的XML映射文件

这个分层就是标准的Controller→Service→Mapper三层调用。很多刚入门的人容易犯的错是把业务逻辑全写在Controller里，表面上看代码很短，但后续一旦要写单元测试、要复用逻辑，就会非常痛苦。这个项目里Service层的存在感很明显，比如创建订单时扣减库存、计算订单总额这种核心逻辑，都在Service里完成，Controller只负责参数校验和结果返回。

3.2 一次“新增商品”操作在代码里怎么流转

我用一个最典型的“新增商品”流程来演示完整链路。前端Vue页面上的表单填好商品名、分类、价格、库存后，点击提交，发生的事情如下：

前端请求交给Axios实例，统一拼接baseURL，一般长这样：

// src/api/product.js import request from '@/utils/request' export function addProduct(data) { return request({ url: '/product/add', method: 'post', data }) }

后端对应的Controller会接收到这个POST请求：

@RestController @RequestMapping("/api/product") public class ProductController { @Autowired private ProductService productService; @PostMapping("/add") public Result add(@RequestBody Product product) { productService.addProduct(product); return Result.success(); } }

注意@RequestBody这个注解，它做的事情是把前端传递过来的JSON字符串反序列化成Java对象。中间不能有字段名不一致的情况，比如前端传的是productName，后端实体类里叫name，那就会绑定失败。接下来到了Service层，它会先做个基础校验，比如商品名不能为空、价格不能为负数，然后调用Mapper写库。MyBatis的XML里对应一条insert into product(...) values(...)语句。

这个链路理解透了，你就能明白为什么很多教程反复强调“前后端字段一致性”。我实际跑下来，这套代码里前端和后端的字段命名是比较统一的，所以单独调试基本没有出现绑定不了的奇怪问题。

3.3 前端工程结构：每个目录负责什么

如果你打开前端目录，通常会看到：

src ├── api # 按模块拆分的接口请求文件 ├── router # 路由配置，含登录守卫 ├── store # Vuex状态管理，存token和用户信息 ├── views # 页面组件 ├── components # 公共组件 ├── utils # 封装Axios请求、工具函数 ├── App.vue └── main.js

这个结构里最值得关注的是utils/request.js。几乎所有管理后台都会在这里对Axios做一层统一封装：请求拦截器自动携带token，响应拦截器统一处理HTTP状态码和业务错误码。你要是拿到手的源码里没有这一层，每个页面都手动拼请求头，那维护起来就是灾难。这套代码里拦截器的处理算得上规范，比如后端返回401时，前端会自动清除本地登录状态并跳转回登录页，不用每个页面重复写跳转逻辑。

路由守卫这块也要提一下。Vue Router允许在跳转前设置拦截：

router.beforeEach((to, from, next) => { const token = localStorage.getItem('token') if (to.path !== '/login' && !token) { next('/login') } else { next() } })

这个逻辑看上去简单，但它是整个系统安全性的第一道门。它对前端页面的意义在于：一个没登录的人无法通过改URL直接跳到后台管理页。当然，前端守卫只是体验层的控制，真正的权限校验还在后端接口上，这也是我后面要反复强调的一点——永远不要只靠前端挡权限。

3.4 那些容易被忽略的全局配置

我建议你启动之前先看一下config包和application.yml。跨域配置很可能藏在这里。前后端分离项目开发时，前端跑在http://localhost:8080，后端跑在http://localhost:9090，这两个端口不同，浏览器出于同源策略会拦截Ajax请求。如果后端没有做跨域配置，前端页面大概率会报Access-Control-Allow-Origin错误。成熟的解决方案是在SpringBoot里写一个WebMvcConfigurer：

@Configuration public class CorsConfig implements WebMvcConfigurer { @Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping("/**") .allowedOrigins("http://localhost:8080") .allowedMethods("*") .allowedHeaders("*") .allowCredentials(true); } }

另一处容易被忽略的是MyBatis配置。很多项目里application.yml会配map-underscore-to-camel-case: true，它的作用是把数据库字段order_no自动映射成Java属性orderNo。没有这个配置，你就要在XML里手动写resultMap，能写到你手酸。这批细节就是源码和“刚写出来的Demo”之间的差距。

4. 数据库表结构解读：一张订单表拆成两张的细节在哪

4.1 商品分类为什么要独立成表

我见过不少新手设计数据库，喜欢直接在商品表里放一个category字段，比如“单板”“双板”“固定器”。短期看确实简单，但如果后期想调整分类名称，就得写一堆update语句，而且分类和商品的关系无法统计。这套系统的做法是把分类独立成category表，商品表通过category_id关联。这样既方便调整分类，也为后续扩展“品牌”、“系列”等维度留好了口子。雪具这种行业，商品信息必须细到具体规格，所以商品表里通常会预留size、color、brand字段。真正做得更好的系统还会引入sku表做规格组合，但这套系统的业务规模下，商品表直接挂规格字段已经够用。

4.2 订单主表和订单明细表拆分的原因

这是整个数据库设计里最经典的一个点。为什么一个订单不能只用一行记录？因为一笔订单可能同时包含雪板、固定器、雪镜三样商品。如果全部挤在订单表里，字段就得写成product1_id、product2_id、product3_id，这显然是反模式——商品数量不固定，扩展性为零。所以正确做法是拆成两张表：

主表记录一次订单的整体信息，明细表记录这次订单里具体买了哪些东西。为什么明细表里要冗余一个product_name？因为商品名称和价格是会变的，今天卖1900的雪鞋，三个月后可能改成1600还改名了。你的订单历史是历史事实，不能跟着商品表的变更一起漂移，所以在下单那一刻把商品名称、单价快照进明细表，才是最稳妥的做法。这个细节在工作面试里经常被问到，能讲清楚的人说明真的理解关系型数据库设计。

订单状态建议用int数字而不是字符串，比如0待付款、1已付款、2已发货、3已完成、4已取消。原因很简单：数字便于比较和流转控制，也不容易因为中英文空格大小写产生脏数据。

4.3 库存表是不是单独建更好

这套系统的设计里，库存数量直接挂在商品表上，通过stock字段管理，下单时更新商品库存。这样做在业务简单时没问题，但如果你追求可追溯性，我更建议增加一张inventory_record库存流水表：

CREATE TABLE inventory_record ( id INT PRIMARY KEY AUTO_INCREMENT, product_id INT NOT NULL, change_type TINYINT NOT NULL COMMENT '1入库 2出库 3盘盈 4盘亏', change_quantity INT NOT NULL, operator VARCHAR(50), create_time DATETIME DEFAULT CURRENT_TIMESTAMP );

为什么要加这张表？想象一个场景：老板月底盘点发现某款雪鞋数量对不上，如果没有流水，你根本不知道多出来的是因为进货没登记，还是少的是因为卖出去漏登记。有了流水表，入库单、销售单、盘点单全都对得上，账实不符的问题才能定位到具体操作环节。这套系统在原版里不一定带这个流水表，但从实用性角度，我建议你上手后自己加上，属于成本极低收益却很高的改动。

4.4 会员表和积分计算的基本原则

会员表的核心字段无非是name、phone、level、points。需要注意手机号这类字段建议加唯一索引，防止同一客户被重复建档。积分计算的通用做法是：订单状态变为“已完成”时，按订单金额比例（比如1元=1积分）累加到客户积分上；订单取消时不加不扣。积分的恢复逻辑也要想清楚——如果一笔订单被取消但积分已经发放，就要做扣减补偿。这些细节不需要一开始就设计得多复杂，但表里要有地方存，逻辑要有地方写。

5. 从拿到源码到浏览器正常显示，完整启动流程与验证清单

5.1 环境准备：先把这些工具装齐

这套系统虽然是“可直接运行”，但你的机器得先具备最基本的Java Web开发环境。我整理了一张环境清单，版本建议是针对这类项目最稳妥的组合：

这里有一个容易踩的坑：Node不是越新越好。Vue2生态的老项目经常依赖node-sass，而node-sass对Node版本有严格限制。如果你装的是Node 18甚至20，安装依赖时报错连篇是家常便饭。我没法给一个放之四海而皆准的版本，但如果你拿到的源码刚好用的还是node-sass，用Node 14是最省心的选择。

5.2 数据库初始化：先有表才能跑接口

环境装好之后，第一步永远是数据库初始化，而不是启动后端。为什么？因为SpringBoot启动过程中如果连不上数据库、或找不到表，大概率直接抛异常干干净净地退出。

操作很简单：先在MySQL里创建一个和项目配置同名的数据库，比如snow_sales，然后导入项目里提供SQL脚本。注意SQL文件的编码，最好用UTF-8，否则中文注释或数据可能变成乱码。命令行方式如下：

mysql -uroot -p create database snow_sales default character set utf8mb4; exit; mysql -uroot -p snow_sales < snow_sales.sql

选utf8mb4而不是utf8，因为utf8mb4才能完整支持特殊字符和emoji（虽然入库的滑雪推文可能偶尔带个⛷️符号）。导入完成后，登录MySQL看一眼表是否齐全：show tables;。

5.3 修改配置文件：唯一必须动的地方

接下来打开后端的application.yml，找到数据源配置，改成你自己的数据库账号密码：

spring: datasource: url: jdbc:mysql://localhost:3306/snow_sales?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: 改成你自己的密码 driver-class-name: com.mysql.cj.jdbc.Driver

有几个参数建议保留：characterEncoding=utf8保证中文不乱码，serverTimezone=Asia/Shanghai解决MySQL 8驱动默认UTC时区和本地时间差8小时的问题，useSSL=false避免证书校验失败。如果你本地MySQL是5.7，驱动类通常写com.mysql.jdbc.Driver，和8.x的写法不一样，需要同步调整。

5.4 按顺序启动，别搞反了

我的习惯是严格按“先后端、再前端”的顺序启动。先后端：

cd snow-sales-backend mvn spring-boot:run

控制台出现Started SalesApplication且没有红色错误，说明后端启动成功。你可以顺手在浏览器访问一个接口验证，比如http://localhost:9090/api/product/list，如果能看到JSON数据，说明数据库和接口都正常。后端项目配置里本地端口很常见是9090，也有项目用8080，以你的application.yml里的server.port为准。

再启动前端：

cd snow-sales-frontend npm install npm run dev

npm install这一步下载依赖耗时因网络而异，如果卡在个别包上，可以换成国内镜像源：

npm install --registry=https://registry.npmmirror.com

如果项目里恰好用了node-sass版本，执行npm install时经常因为下载二进制文件失败而报错，这时候除了换镜像源，还可以尝试：

npm install node-sass --sass-binary-site=https://npmmirror.com/mirrors/node-sass/

前端启动成功后，控制台会打印Local: http://localhost:8080，浏览器打开就能看到登录页。

5.5 验证系统正常工作的几个检查点

页面能打开不等于系统正常。我每次部署完都会按下面的清单过一遍，节省很多返工时间：

1. 登录：使用源码里提供的管理员账号登录，看是否能跳转到首页。
2. 新增商品：在商品管理页新增一条测试数据，页面列表能不能立即刷新。
3. 创建订单：给某个会员下一笔包含两件商品的订单，确认金额自动计算正确。
4. 扣库存：下单后回商品列表，看看对应商品的库存是否减少。
5. 看统计：首页统计卡片的数据是否和刚才的操作对得上。
6. 刷新会话：F12清掉localStorage里的token，重新刷新页面，看是否被强制跳回登录页。

这六步走完，基本可以判断这套系统在你机器上不是“表面启动”，而是真正能支撑业务流程的。

6. 我带着这套代码跑了三遍，遇到的坑和解决方法

6.1 前端依赖安装失败的几种典型原因

第一遍跑的时候，我卡在npm install上超过半小时。表面上是依赖在报错，实际上是三个问题叠加：Node版本太高导致node-sass编译失败；镜像源默认走官方源导致下载缓慢；以及某些包版本之间的peer dependency冲突。处理顺序是：先确认Node版本，如果项目锁文件里带node-sass，直接考虑换Node 14；再设镜像源；最后如果还报冲突，把node_modules整个删掉重新安装一次。很多情况下重新安装能解决莫名其妙的问题，因为断点续传和缓存可能导致依赖树不完整。

6.2 MySQL 8连接报错：驱动类、SSL、时区三连

如果你用的是MySQL 8，但项目里还写的是旧驱动类com.mysql.jdbc.Driver，启动时大概率会报ClassNotFoundException或者警告说驱动类已过时。MySQL 8以后正确的写法是com.mysql.cj.jdbc.Driver。另外两个高频报错上面已经提过——serverTimezone不设置会报时区错误，useSSL不设置或设为true有时会报证书相关警告。遇到这些问题不要慌，它们本质上是配置缺参数，不是代码逻辑问题，我在旧笔记本上跑一遍踩全了。

6.3 前端页面上显示“请求失败”，但后端接口明明没问题

这个现象的常见原因是跨域配置没生效。如果前端不管怎么调，浏览器Network面板里请求都是红色报错，而你把同样的URL直接放到浏览器地址栏却能返回数据，基本可以断定是跨域问题。解决办法是回到第3.4节提到的WebMvcConfigurer，确认allowedOrigins里写的前端地址和你npm run dev打开的地址完全一致，注意端口号差一个数字都不行。如果前端地址是动态的，也可以直接在开发阶段用allowedOriginPatterns("*")放开，仅在本地测试没问题，上线前再收紧。

6.4 IDE里一片红：Lombok没装或没开启

源码里如果大量使用@Data、@Getter、@Setter这类注解，你的IDE必须安装Lombok插件并在设置里开启Annotation Processing。否则会出现一个奇怪现象：代码在命令行用Maven打包完全正常，但在IDEA里打开满屏红色报错，说找不到getXxx()方法。这个坑特别容易劝退新手。解决方法是：IDEA安装Lombok插件，然后在Settings -> Build, Execution, Deployment -> Compiler -> Annotation Processors勾选Enable annotation processing，再重启项目，红就消了。

6.5 启动时端口被占用：有时候不只是换数字那么简单

后端启动报Port 9090 was already in use，最简单粗暴的办法确实是换端口，但如果你改端口，记得同步改前端request.js里的baseURL。很多前后端分离项目把所有API路径配置写死在拦截器封装里，你后端换了9091，前端还在请求9090，就会陷入“后端明明启动成功，页面却一直报错”的困惑。另一种更彻底的处理方式：

# Linux / Mac lsof -i :9090 kill -9 进程号 # Windows netstat -ano | findstr 9090 taskkill /pid 对应PID /F

把占用端口的旧进程杀掉，比改配置更省事，也不用担心漏改前端引用。

7. 如果雪具店真的上线这套系统，我建议这样二次改造

7.1 把“销售系统”扩展成“销售+租赁”双模式

很多滑雪门店真正的主营业务不止是卖装备，雪季里雪板租赁、雪鞋租赁的收入甚至超过销售。现有系统如果要接租赁业务，最自然的做法是在订单体系上加一个order_type字段，区分销售订单和租赁订单；再单独建一张rental_record表，记录租借开始时间、预计归还时间、实际归还时间、押金金额。计费逻辑可以按天计费，也可以按雪季套餐计费。核心难点是超期费用的自动计算，这部分建议写成独立的Service接口，方便后续对接支付。

7.2 库存预警和采购建议：让系统从“记录”变成“决策”

纯记录数据的系统价值有限，我更喜欢让系统替人做判断。改造方案很简单：在商品表加一个low_stock_threshold字段（比如10），每天跑一个定时任务或写一个查询，把库存低于阈值的商品列出来，按最近30天销量给出建议采购数量。对于雪具这类季节性很强的行业，你甚至可以结合历史销售数据，在雪季来临前自动生成备货清单。SpringBoot做定时任务只需要一行@Scheduled注解，技术门槛很低，但业务价值提升很大。底层原理也不复杂：无非是“当前库存”“日均销量”“采购提前期”三个数字的加减乘除，却能让小老板每天少操很多心。

7.3 商品图片接入MinIO：别再把图片丢在本地磁盘里

热词里有人搜minio加入到springboot，说明不少人在做类似的扩展。如果你直接在管理后台给商品加图片，第一种方案是把图片存到本地磁盘，但这样部署到服务器后，图片会丢，迁移麻烦。更合适的方案是引入MinIO这个对象存储中间件，把图片上传到MinIO，数据库里只存访问路径。MinIO对开发者很友好——部署简单，有现成的Java SDK，还支持私有桶+临时授权链接。找一台低配服务器就能跑，成本几乎可以忽略。对这套系统来说，改造点就两个：后端加一个上传接口，前端把文件上传从base64改为直传MinIO。这一步做完，整体专业度会提升一大截。

7.4 权限控制再往前走一步：角色与动态路由

原系统一般只有管理员和普通操作员之分，菜单也是固定写死的。如果想更细腻一点，可以引入角色表role、用户角色关联表user_role、角色菜单关联表role_menu。后端用拦截器或注解做接口级权限校验，前端根据登录用户返回的菜单列表，用Vue Router的addRoutes动态注册路由——这就是热词里vue动态路由对应的实际场景。有个原则必须坚持：前端隐藏菜单只是体验优化，后端的接口校验才是权限真正的保证。攻击者完全可以自己构造一个请求去调删除接口，如果后端不做校验，菜单藏得再好也无济于事。

最后再分享一点我个人的体会。每次拿到一套源码，我习惯先不看运行结果，而是顺着Controller往里翻一遍Mapper，自己先画一遍业务流程图，再去启动和测试。这套雪具销售系统我在几个环境里跑过，比较推荐的做法是：先按原版跑通，跑通之后选一个最贴近你实际业务的方向做一个小改造，比如加一张库存流水表，或者加一个销售排行接口。不要一上来就大改，小步快跑才能保持动力。等第一版改动稳定了，你会发现那些以前觉得神秘的SpringBoot项目，其实也就是“一个请求进来，经过几层代码，操纵几张表”这么回事。