企业官网建设流程全解析

又到了毕业设计选题和中小型项目练手的高峰期，我几乎每周都会被问同一个问题：“有没有什么既不算太复杂、又能把主流技术栈都串起来、还能讲清楚业务逻辑的选题？”我的建议通常就一个——基于Spring Boot + Vue的智能仓储超市系统。原因很直接：它既有传统CRUD的底子，又有库存预警、出入库流水、销售看板这类带业务深度的模块，足够覆盖从后端接口设计到前端数据可视化的一条完整链路，却不会像电商秒杀系统那样把并发和一致性门槛拉得过高。这篇文章我打算把自己在设计和实现这类系统时沉淀下来的经验完整梳理一遍，从数据库建模、权限设计、库存事务处理，到前端权限路由、看板可视化、部署上线的完整路径，把我踩过的坑和优化思路都写出来，给正准备动手的同学和想提升项目质量的开发者做一个可以直接参考的实操手册。

1. 为什么仓储超市系统是练手项目里的“高性价比选择”

先聊选题逻辑。很多同学一上来就奔着“高并发秒杀”“微服务拆分”去，结果做了两个月还在调环境，代码却没写几行。仓储超市系统的好处在于，它处在一个非常舒服的难度带：业务模型足够清晰，谁都能理解仓库里得有商品、入库、出库、库存、预警这些概念，需求不需要东拼西凑；技术栈又足够主流，Spring Boot在前端分离开发里就是事实标准，Vue更是面试和工作中绕不开的前端框架。两者一组合，你CV里写出去就是“前后端分离全栈项目”，而且每一个模块都能往深了讲。

这个系统的业务闭环大概是这样的：超市采购员录入商品信息、管理供应商；仓库管理员处理入库单和出库单，库存随之变化；收银员在前端收银台完成销售，系统自动扣减库存；系统定时扫描发现某些商品低于安全库存后自动生成预警记录；最后通过数据看板把本周销售趋势、库存周转、商品排行直观展示出来。你看，这个闭环里既有基础的增删改查，也有库存流水、销量统计这些核心业务逻辑，覆盖了典型企业管理系统的绝大部分场景。

从学习角度来说，这个项目能帮你把几件重要的事情一次过都练到：

• 数据库设计：表怎么拆、外键和冗余怎么权衡、流水表和汇总表各承担什么角色。
• 权限与安全：登录鉴权、JWT、路由级权限、按钮级权限怎么落地。
• 复杂事务处理：入库扣减库存时怎么保证数据一致性，并发下怎么防止超卖。
• 前后端联调：接口规范、统一响应体、跨域处理、axios拦截器。
• 部署上线：后端打成jar包、前端构建静态文件用nginx托管，整套流程跑通。

这些能力不像单纯刷算法题能立刻量化，但在实际工作和毕业答辩里都非常加印象分。我要强调的一点是，千万不要把“智能”这个词理解得太玄乎。在仓储超市场景里，所谓的智能主要体现在两个地方：一是基于阈值和数据统计的自动预警，二是通过可视化看板辅助经营决策。把这两个部分做扎实做漂亮，项目就已经比大多数停留在CRUD层面的作品高一截了。

2. 业务模块划分与数据库设计：先把地基打好

我见过的烂项目里，十个有八个都是建表太随意，后面改接口改到崩溃。仓储超市系统虽然不算复杂，但涉及的角色和单据类型不少，表结构设计得是否合理，直接决定后续编码是顺畅还是天天返工。我的建议是先花两三天时间把数据模型理清楚，想清楚每个表承担什么职责，再动笔画实体类。

2.1 用户与权限模型

一个典型的仓储超市系统至少需要三种角色：管理员、仓库操作员、收银员，可能还会有只读的统计报表角色。我的设计是尽量不把角色属性写死在user表里，而是采用“用户-角色-权限”的经典模型，用三张表维护：user表存账号、密码（加密存储）、昵称、状态、创建时间；role表存角色编码和角色名；user_role表维护用户和角色的关联。至于菜单和按钮权限，放前端来做动态路由过滤更灵活，后端只需要给当前用户返回角色标识列表即可。

有人会觉得小型项目搞这么复杂是不是过度设计，但我的实际感受是：权限模型一开始就做标准，后面加模块、加角色只是追加数据，不用改代码。特别是做毕设时，答辩老师很容易问的第一句话就是“你这个系统怎么保证不同角色看不到不该看的菜单”，如果一开始就用了用户-角色-权限模型，这个问题你就能答得很从容。

2.2 商品、库存与供应商表设计

商品表product是核心基础表，字段建议包括商品ID、商品编码、条码、名称、分类ID、规格、单位、售价、成本价、安全库存、启用状态、创建时间。这里有几个容易被忽略的细节：

• 条码字段建议设为唯一索引。超市场景里条码是扫码录入的凭据，不唯一会造成商品混乱。
• 安全库存单独建字段，不要写在备注里。预警逻辑全靠它。
• 售价和成本价分开。统计毛利的时候必须有两个价格源，只存售价会让自己后面测报表时无从下手。

库存字段我倾向于不在product表里直接维护一个stock字段，而是设计独立的库存表inventory，这个表记录product_id、仓库ID（如果你有多个仓库）、当前库存量、占用量、更新时间。好处是当商品表和库存表的查询频率不一致时，可以独立扩展，而且库存操作的并发锁可以挂在inventory表的行上，不至于和商品信息的更细锁混在一起。单仓库部署的话，inventory表也建议保留，后续如果有门店扩展需求就不用重构。

供应商表supplier就相对简单了，主要维护供应商名称、联系人、电话、地址、备注、状态。要注意在入库单表里关联供应商ID，而不是存供应商名称字符串——我见过不少项目图省事在单据里直接存名称，结果供应商改了名字，历史单子全显示错误，排查起来极其痛苦。

2.3 核心单据：入库单、出库单与库存流水

仓储系统里最不能省的表就是单据主表、单据明细表和库存流水表。我常打的一个比方是：库存表是“余额”，流水表就是“银行流水”，你光看余额看不出账怎么动的，必须每笔变动都有来龙去脉。所以我的核心表设计是：

• stock_order（出入库单主表）：单号、类型（入库/出库/盘点调整）、供应商ID、操作人ID、总金额、状态、备注、创建时间。
• stock_order_item（单据明细表）：主表ID、商品ID、数量、单价、金额。
• stock_flow（库存流水表）：商品ID、变动类型（入库/出库/销售/盘点/手工调整）、变动数量（正负表示）、变动前库存、变动后库存、关联单号、操作人ID、创建时间。

这里我想重点说下为什么一定要加库存流水表。先说个实际场景：某天你收到反馈，说某个商品本来库存应该是30，结果店里显示成了12。你如果没有流水表，就只能在代码里各种猜，完全无从下手；如果你有流水表，搜一下该商品的流水记录，就能看到哪一笔异常的变动把库存扣多了，数据对得上还是对不上立刻清楚。对于答辩也是一样，库存流水表能引出你对“系统可追溯性”这个设计原则的理解，这是一个明显的加分项。

采购入库的数据流是：入库单主表插入记录 → 明细表逐行插入 → 逐行更新inventory库存 → 逐行生成库存流水。整个过程必须放在同一个事务里。这也是Spring框架里@Transactional注解最经典的使用场景，后面我会专门讲代码实现细节。

此外，销售端建议创建sale_order和sale_order_item表，记录每笔收银的订单和销售明细。它一方面是流水线扣减库存的业务来源，另一方面也是数据看板里“今日销售额”“本周销售趋势”等统计SQL的数据源。如果你统计销售报表时居然是从库存流水里反推，那就是绕远路，还容易因为盘点调整记录污染统计数据。

2.4 预警与日志表

预警这块我有两种实现方式。一种是直接写SQL查询“当前库存小于安全库存”的商品列表，这种方案适合做“拉取式”预警，页面每次打开都能看到最新状态，实现简单且永远不脏。另一种是系统每天用定时任务扫描一遍低库存商品，把预警记录写到stock_alert表，记录商品ID、预警类型、预警时库存、状态（已处理/未处理），这样可以记录“历史预警”，也支持对“处理动作”进行跟踪。

我的实际做法是两者结合：看板和首页预警用实时查询，保证准确；同时定时任务每天落一次预警记录，方便查历史。别觉得这是重复劳动，等你在答辩过程中被问到“低库存商品有哪些历史预警记录”时，你就会理解这个冗余的价值。

操作日志表operation_log也是一样。我见过很多项目完全没做操作日志模块，后来用户问“这个入库单谁建的？这个库存怎么被扣了？”完全答不上来。我的建议是核心单据的新增、修改、删除操作都往日志表里写一条，字段包括操作人、操作模块、操作类型、操作内容摘要、IP、操作时间。这个模块本身代码量不大，但能极大提升系统的完整度。

3. Spring Boot后端实现要点：权限、事务与统计

后端我使用的是标准的Spring Boot 2.x + MyBatis Plus + MySQL的组合。MyBatis Plus在单表CRUD上省了我大量写XML的时间，分页插件也开箱即用，适合这种以管理后台为主的系统。但涉及多表关联和复杂统计的SQL，我坚持手写XML，不图省事用QueryWrapper硬拼，后面查性能排问题会头疼死。

3.1 登录鉴权与细粒度权限控制

登录接口这块我选择Spring Security + JWT的组合。流程是这样的：用户提交用户名和密码，后端校验通过后签发一个JWT，把用户ID、用户名、登录时间封装进去，token有效期设置为24小时，前端存起来后每次请求都带在Authorization头里。后端写一个JWT过滤器，从请求头解析token，校验签名和有效期，再把用户信息塞进SecurityContext里供Controller使用。

密码存储明文是绝对红线。我用的BCryptPasswordEncoder做加密，它是慢哈希算法，自带盐值，即使两个用户密码相同生成的密文也不一样。这一点答辩时一定要主动提，能从侧面证明你具备基本的安全意识。

权限这块我刚才提到过用户-角色-权限模型，落地到后端，我会给接口加上@PreAuthorize("hasAuthority('product:edit')")这类注解。比如增加商品是product:add，删除商品是product:delete，审核入库单是stock:audit。这样不同角色的权限配置就非常清晰，只要在数据库里给角色绑定对应的权限字符串即可。做这个设计的时候一定要把权限点列全再动手建表，不然后期加注解改接口很麻烦。

3.2 库存事务处理的关键代码逻辑

这应该是整个系统后端最核心的部分。我以“采购入库”为例拆分一下流程：前端提交入库单，包含供应商ID和商品明细列表；后端接收到请求后在一个事务方法里完成一系列操作；先根据单号查重确保不重复提交；再对明细里的每个商品做库存更新；更新方式是执行一条UPDATE语句把库存加上，同时记录流水。

我这里要敲黑板强调的是并发场景。假设货架上某商品当前库存是10，同时有两个收银员各自卖出了1件，如果代码是先SELECT库存再UPDATE，那么两次SELECT到的都是10，各减1后库存变成9，但实际应该是8。解决思路有两个方向：

• 乐观锁：在inventory表加版本号version，UPDATE时带条件version = #{oldVersion}，并让version自增，如果更新影响行数为0说明数据已被别人改过，重新读取再试。
• 条件更新：直接把业务条件焊死在UPDATE语句里，比如UPDATE inventory SET stock = stock - #{num} WHERE product_id = #{productId} AND stock >= #{num}。只要更新行数为1，就说明扣减成功；如果为0，说明库存不足或商品异常，直接抛异常回滚事务。

我的做法是偏向后者的，因为实现最简且性能最好。下面给个关键代码示意：

@Transactional(rollbackFor = Exception.class) public void inboundStock(InboundOrderVO order) { // 1. 主表写入 StockOrder orderEntity = new StockOrder(); orderEntity.setOrderNo(generateOrderNo("RK")); orderEntity.setSupplierId(order.getSupplierId()); orderEntity.setType(1); orderEntity.setTotalAmount(order.getItems().stream() .mapToDecimal(Item::getAmount).sum()); stockOrderMapper.insert(orderEntity); // 2. 明细写入 + 库存更新 + 流水记录 for (InboundItemVO item : order.getItems()) { StockOrderItem detail = new StockOrderItem(); detail.setOrderId(orderEntity.getId()); detail.setProductId(item.getProductId()); detail.setQuantity(item.getQuantity()); detail.setPrice(item.getPrice()); stockOrderItemMapper.insert(detail); // 关键：条件更新库存，并用返回值判断是否扣减成功 int rows = inventoryMapper.increaseStock( item.getProductId(), item.getQuantity()); if (rows == 0) { throw new BizException("商品不存在或库存状态异常: " + item.getProductId()); } // 获取变动前库存用于流水记录，避免并发脏读 Inventory inventory = inventoryMapper.selectById(item.getProductId()); StockFlow flow = new StockFlow(); flow.setProductId(item.getProductId()); flow.setChangeType(1); flow.setChangeQty(item.getQuantity()); flow.setBeforeStock(inventory.getStock() - item.getQuantity()); flow.setAfterStock(inventory.getStock()); flow.setRefOrderNo(orderEntity.getOrderNo()); stockFlowMapper.insert(flow); } }

出库、销售扣减库存的逻辑和这几乎镜像，只是把increaseStock换成decreaseStock，并且一定要带stock >= #{num}这个条件，防止扣成负数。关于流水表里的beforeStock（变动前库存），我有个经验是：直接靠UPDATE之后再SELECT一次，然后用当前值减掉变动数量倒推变动前值，这样写出的流水永远是正确的，不会存在并发下前后顺序颠倒的问题。

3.3 数据看板背后的统计查询

看板是“智能仓储”这个定位的视觉化核心。我的看板包含四个模块：今日销售概况（销售额、订单数、销售商品件数）、近7天销售趋势折线图、商品销售排行TOP10、低库存预警列表。数据来源是SQL聚合，简单说就是把sale_order、sale_order_item和product表join起来做分组统计。

近7天销售趋势的SQL思路是：

SELECT DATE(create_time) AS day, SUM(total_amount) AS amount FROM sale_order WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(create_time) ORDER BY day;

从后端接口返回给前端时，我会在VO里补好日期序列，缺数据的日期补0，避免前端绘图出现跳点。商品销售排行TOP10就是按商品分组求和销量再排序取前10条。低库存预警则是一条实时查询的SQL：

SELECT p.id, p.name, p.safety_stock, i.stock FROM product p LEFT JOIN inventory i ON p.id = i.product_id WHERE i.stock <= p.safety_stock ORDER BY (i.stock - p.safety_stock) ASC;

这里有个细节：ORDER BY用的是库存与安全库存的差值，能直观看出哪个商品缺口最大、最需要紧急补货，比单纯按库存量排序更能反映真实情况。

3.4 批量导入导出：Excel读写方案

超市SKU动辄几百上千，商品信息如果靠手工一个个录入，体验会非常差，所以批量导入导出成了刚需。我用的阿里开源的EasyExcel，底层是SAX模式流式解析，不会像POI那样把整个工作簿加载进内存，几万行数据也不会OOM。

导入的流程是：前端用Element Plus的upload组件把Excel文件传上来，后端先做格式校验（表头列是否齐全），再逐行解析，校验条码唯一性，商品已存在的走更新逻辑，不存在的走新增逻辑。这里要谈点经验，不要在校验完所有行之前就批量写入，应该先把所有行解析成对象列表、统一做合法性校验（比如售价不能为负、条码不能为空），等全部校验通过后再分批插入，一批500条，千万不要一行一插，那个性能差距到了真实数据量会非常明显。

导出则简单很多：查询商品列表，按模板格式填充数据，用EasyExcel写出到HttpServletResponse输出流里即可。我习惯在导出时设置一个列宽和表头样式，虽然代码会多几行，但用户拿到的文件观感好很多。

4. Vue3 + Element Plus前端：从登录到看板的完整实现

前端我用的是Vue3 + Vite + Element Plus + Pinia + Vue Router + Axios + ECharts这套组合。也许有人还在纠结Vue2和Vue3选哪个，我的建议很直白：新项目直接Vue3，组合式API写起来清爽，而且现在绝大多数新工作都用Vue3，练手项目选Vue2反而是给自己添堵。下面把关键部分的实现逻辑和思路梳理一遍，不会贴完整代码，重点讲清楚设计意图。

4.1 登录页与请求封装

登录页我用Element Plus的表单组件做校验，用户名密码必填，校验通过后调用后端/auth/login接口。拿到token后，我用Pinia存到store里，同时持久化到localStorage，刷新页面不丢登录态。之后axios封装的请求实例中写一个请求拦截器，统一从store里取token并塞进请求头：

service.interceptors.request.use(config => { const token = useUserStore().token if (token) { config.headers.Authorization = `Bearer ${token}` } return config })

响应拦截器里统一处理状态码：200表示成功直接返回数据；401表示token失效，清掉本地登录态并跳回登录页；其他业务异常则用Element Plus的Message组件弹出后端返回的错误信息。这里我踩过一个坑：后端返回的业务状态码和HTTP状态码容易混。我的最终约定是——HTTP状态码只表达“请求是否被处理”，业务成功与否看响应体里的code字段。这看似小事，但前后端各写各的，联调时非常容易乱。

4.2 动态路由与权限控制

仓储超市系统有三种角色，不同角色看到的菜单不一样。管理员能看到系统管理菜单，仓库操作员只需要出入库和库存查询，收银员只需要前台收银模块。实现思路是：用户登录后请求后端获取当前用户的角色和权限列表，存到Pinia中；前端定义好一个asyncRoutes数组，每个路由的meta里声明roles字段，比如['admin', 'operator']；然后写一个filterAsyncRoutes函数，根据当前角色过滤出可见路由，再通过router.addRoute()动态注册。

还要强调一个很容易遗漏的点：Vue Router按需加载组件时，如果用() => import(viewPath)这种字符串拼接方式传动态路径，打包的时候Webpack/Vite不一定能解析，必须保证import里的路径是静态的。我的做法是维护一个视图组件的映射表，用路由name去对应组件，例如const modules = import.meta.glob('../views/**/*.vue')，再通过模块的key匹配。这个方案既支持动态路由，又绕开了动态import字符串的解析坑。

路由守卫也不能漏。我写的是全局前置守卫：如果访问的页面需要登录且本地没有token，就重定向到/login；如果已经登录但访问的是登录页，就重定向到首页。权限校验在动态路由注册后会自动生效，不需要在守卫里再做二次判断，这样代码结构最清晰。

4.3 看板页与ECharts集成

看板页是全项目的门面，做得好的话观感提升非常大。我用的ECharts，在项目里封装了一个BaseChart组件，接收配置项对象作为prop，内部负责初始化实例和监听窗口resize事件。统计接口返回的数据结构我统一封装成{ dates: [], amounts: [] }这种平行数组，在前端组装成ECharts需要的[date, amount]格式。

大家做可视化的时候要留个心眼：ECharts的容器div必须有明确高度，否则图表渲染不出来或者显示得很小。我一般给容器设height: 360px，或者通过CSS flex布局让容器撑满父级。另外，setOption之前要决定是merge还是replace，我的习惯是每次都用notMerge: true强制全量替换，避免上次的图例和这次的图例叠加导致状态混乱。

4.4 公共组件与页面复用

后台管理页面的表格、弹窗表单、分页、搜索条长得都很像，如果每个页面都复制一份代码会累死人。我封装了几个实用组件：TablePage组件负责搜索区、表格、分页的框架；DialogForm组件负责表单弹窗，通过slot插入具体表单项；ImportButton组件负责上传Excel并显示导入结果。前端组件的抽象程度不要一股脑搞太高，我的经验是“重复三次以上才考虑抽取”，过早抽象容易为了通用而把简单场景搞复杂。

5. 疑难问题与排查思路：我在项目里踩过的坑

做这个系统的过程中，我踩过几个挺让人头大的问题。有些问题代码写得快根本发现不了，只有跑到真实场景下才暴露。下面挑几个高价值的分享，这些内容也是答辩时展示你思考深度的好素材。

5.1 并发扣库存引发的超卖问题

原型的bug是这样：两个收银台同时卖同一件商品，A操作员打开该商品详情页看到库存剩3，B操作员同时也看到了3。A先提交销售单，库存扣到2；B紧接着提交，因为他的页面还显示3，后端如果只按“先select再update”的写法去扣，就会把库存扣到1，等于多卖了一件。表面上是页面没刷新，根因却是库存扣减没有与“库存量”做原子性校验。

解决方案就是我前面提到的条件UPDATE。这个坑的排查过程很有意思：我一开始直接怀疑前端是不是用了缓存或者异步刷新出了问题，后来盯着数据库日志看了半天才发现，两次请求几乎是同一毫秒进来的，第一条UPDATE和第二条UPDATE之间没有区分是否基于同一初始值。症结锁定在SQL层面之后，问题就迎刃而解了。这里多说一句，做这类排查要学会看数据库的慢查询日志和general log，不要只靠肉眼推断。

5.2 动态路由注册后刷新页面404

项目刚跑通时的痛苦回忆：登录进入首页，切换菜单都正常，但只要一刷新浏览器，就跳404。查了半天发现原因有两个层面。第一，动态路由是通过router.addRoute()注册的，但刷新后Pinia恢复store的时候是异步的，在路由守卫执行时路由还没注册完，就匹配不到任何页面。第二，刷新后asyncRoutes根本还没加载回来，自然无从注册。

我的解决思路是：路由守卫中增加一个标志位，第一次进入时如果发现store里还没有菜单数据，就先呼叫后端获取用户信息与权限，等路由注册完成后再next({ ...to, replace: true })重新进入一次目标路由，确保第二次匹配成功。这段流程用await串联，顺序是：检查token → 检查用户信息 → 动态注册路由 → 放行。处理完后刷新页面的404问题就消失了，这个点建议写进答辩“困难与解决方案”里，很能体现实际开发经验。

5.3 文件上传成功但Excel内容解析为空

有一段时间导入商品Excel，接口返回成功，但数据库里一行都没多。排查发现是前端把上传请求的Content-Type设定成了application/json，而后端接口用的是@RequestPart("file") MultipartFile file来接收，两边对不上，文件字段名也对不上（前端传的是uploadFile，后端期望的是file），导致后端拿到的是空文件对象、解析得到空列表。后来我把前端上传组件的:file-name属性与请求字段对齐，并且显式通过FormData构造请求体，解决了这个问题。

这一类问题反复出现在前后端分离项目中，根因都出在“接口契约不明确”。所以我强烈建议在设计接口之前，先列一份接口文档（哪怕就是一份md表格），把URL、请求方法、参数名、参数类型、返回结构定清楚，能省掉后面不知道多少联调口水战。

5.4 跨域与代理配置

开发环境下前端跑在5173端口，后端跑在8080端口，浏览器直接跨域。我的方案是前端Vite配置代理，把请求/api开头的内容转发到http://localhost:8080，这样浏览器眼里请求都是同源，跨域问题直接绕开，也避免了生产上还要为跨域配置一堆漏洞风险的头疼事。生产环境则用nginx把前端静态资源和后端接口放到同一个域下，通过location /api把请求反转给内网后端服务，从根上消除跨域问题。这种方式不仅能解决跨域，还能顺带做一层简单的请求转发，是我比较推荐的生产部署形态。

6. 部署上线与答辩准备的实用建议

项目做完代码只是一半，能把系统跑起来、能讲清楚设计过程，才算是完整交付。部署和答辩这两块其实关联很紧密，我一起说说。

6.1 本地构建与服务器部署流程

后端我会用Maven打成可执行jar包，环境配置通过application-prod.yml独立分环境管理。数据库脚本用Flyway或手工SQL脚本在服务器上执行一次。启动命令我用的是带--spring.profiles.active=prod的nohup方式，日志重定向到文件里方便排查。前端则是npm run build生成dist目录，扔到nginx的html路径下。nginx配置文件里核心是两条：location /指向dist目录做前端静态资源托管；location /api/用proxy_pass转给后端jar服务。这套流程我在本地虚拟机上反复跑通多次，稳定可靠。

服务器资源不用高性能，2核4G的小机器完全够这个系统跑。数据库、后端服务、nginx都部署在同一台机器上时，注意端口规划别冲突，MySQL默认3306，后端我用8080，nginx监听80。生产环境千万别图省事把数据库端口暴露到公网，我都只监听内网地址。

6.2 答辩时的高频问题与应对思路

答辩老师一般不会要求你背诵代码，他们更在意你是否真的理解自己做的系统。我预估并准备了这么几个高频问题：

• 为什么选Spring Boot + Vue这套技术栈？从生态成熟度、开发效率、前后端分离对团队协作的好处、自己后续找工作有利于上手，这几个角度展开。
• 库存预警是怎么实现的？讲清楚安全库存字段、实时查询SQL、定时任务扫描三个层次。
• 如果并发量增大，你这个系统哪个环节会是瓶颈？先承认当前系统的定位是中小型场景，然后提出数据库索引优化、Redis缓存热点商品库存、异步削峰、读写分离这几个演进方向。
• 安全性上做了什么？密码加密、JWT认证、接口权限注解、前端路由权限过滤，这几层都要能说出来。

这些问题忌讳的是满嘴概念却答不上来细节。比如提Redis缓存库存，就必须能说清楚缓存和数据库之间的数据一致性如何保证、缓存击穿怎么防。哪怕方案不完美，只要逻辑闭环，老师会认可你的思考深度。

6.3 让项目更有亮点的扩展思路

如果做完基础版还有余力，我推荐加一个“库存移动平均成本”的计算功能，或者“近保质期商品预警”模块，后者在超市场景里比低库存更贴近业务真实需求。还可以考虑给系统加一个简单的操作数据统计接口，比如每个操作员一天处理了多少单据，相当于轻量的绩效考核看板。这些扩展功能的代码量都不大，但每加一个，答辩时就可以多讲一个业务场景和对应的技术实现，项目的差异化优势立刻体现出来。

这里说句掏心窝的话：答辩时最打动老师的，往往不是功能列表有多长，而是你对某一个业务细节的深入思考。比如你能主动解释“库存流水表解决了数据可追溯性问题”“条件UPDATE解决了并发超卖”“定时预警加实时查询解决了数据实时性和历史追溯的矛盾”，这些设计动机本身就是高质量的答辩输出。

7. 个人实操体会：开发顺序和节奏建议

最后分享一段我个人比较推荐的开发节奏，希望能帮你少走弯路。我建议按这种顺序推进：需求清单和数据库建表 → 后端基础框架和登录权限 → 商品和供应商模块 → 出入库与库存流水 → 销售收银 → 预警与看板 → 前端页面逐个对接 → 联调与部署。这种顺序的好处是每个阶段都能产出可运行的东西，不会出现前两周毫无产出感的焦虑期。

如果是打算用这个系统做毕业设计，我特别想提醒：不要把论文和代码割裂开。一边开发一边记录你的设计决策、遇到的问题、排查过程，最后写论文时这些第一手素材比任何模板都好用。你在做库存事务时想明白的条件更新思路，本身就是论文里“关键技术”章节的绝佳内容。

我在实际参与和指导这些项目时发现一个规律：凡是最后能把“为什么这样设计”讲透彻的同学，项目质量普遍都高一个档次。因为他们不是照着示例代码抄，而是真的在思考系统里的每一个选择。这套基于Spring Boot + Vue的智能仓储超市系统，恰好给了你一个适中的舞台，让你有机会把CRUD之外的那一层业务逻辑想明白、做扎实。希望这篇文章能帮到你，也期待你在这套系统上做出属于自己的亮点。