1. 项目概述与选题初衷每年的毕业设计季总能看见不少同学在选题上左右为难。管理系统类题目被人做烂了但为什么每年还是有一大批人前赴后继我的看法是管理系统恰恰是最适合用来证明你掌握了Web开发全流程的载体。而这一次我打算拆解的项目——springboot基于Java的高校超市管理系统就是一个典型的、用来练手和答辩都非常合适的选题。高校超市和普通社区超市不一样它的用户群体非常固定就是校内师生。这意味着会员管理、校园一卡通对接、多校区库存调拨、临期商品处理这些需求都是真实存在的。从另外一个角度来看超市管理系统覆盖了商品管理、库存管理、收银结算、会员管理、订单管理、统计分析等多个经典业务模块每个模块单独拿出来都可以讲出不少技术点对于毕业设计论文的篇幅填充来说也非常友好。这个系统适合谁三类人第一类是正在选毕业设计题目、想找一套不太难但功能完整的系统的计算机专业学生第二类是打算做前后端分离项目练手、想把Spring Boot全家桶真正用起来的开发者第三类是高校后勤信息化的从业者或相关运营人员可以参考这套系统的模块设计思路。读这篇文章时你不需要有很强的Java基础但如果你已经能独立写一个简单的Spring Boot CRUD项目读起来会非常顺畅。下面我会按照我自己实际做这个项目的流程——从需求分析、技术选型、数据库设计到核心模块实现、答辩准备——一步步拆给你看。2. 项目整体设计与思路拆解2.1 需求分析先搞清楚学校超市到底需要什么在动笔写代码之前最忌讳的就是拿到题目就开干。我见过太多毕设项目做到一半推倒重来的情况根源就在于需求没理清。高校超市管理系统的需求核心要回答几个问题谁在用这个系统用这个系统要完成什么业务角色划分是很清晰的按真实业务来看主要有三端系统管理员负责整个系统的正常运转包括员工账号开通与权限分配、基础数据维护、系统日志查看等。超市工作人员可以继续细分为收银员、理货员和店长。收银员负责前台收银和退货处理理货员负责商品入库上架和库存盘点店长负责查看经营数据报表和审批采购计划。学生/教职工顾客通过线上端查看商品信息、浏览促销活动部分功能完备的版本还支持线上下单、自提。从业务流程来看最核心的是两条一条是进货流程采购员发起采购申请 → 店长审批 → 供应商送货 → 验货入库 → 库存增加 → 生成入库单。这里要注意库存流水必须和财务对得上否则月底盘点账面数量与实际数量不符系统做得再花哨也白搭。另一条是销售流程收银员扫码/输入商品编号 → 系统校验库存 → 生成订单 → 扣减库存 → 结算收款 → 打印小票。如果有会员还要先识别会员身份再计价涉及会员折扣和积分累计。需求文档里的功能清单可以画成表格但真正关键的其实是那些容易被忽略的非功能需求。高校超市有个非常显著的特点——高峰时段集中下课铃一响收银台前面就是长队这就要求系统在并发不高但交易频发的场景下不能卡顿。还有一个容易被忽略的场景断网或者停电时怎么办很多超市会用离线收银兜底但作为毕设不需要做那么深你只要在论文里提到这个风险点并且说明你做了数据校验和日志记录就已经是加分项了。2.2 技术选型为什么是Spring Boot而不是其他做毕设的同学常问一句话“老师我用什么技术栈比较好”我的回答一直很朴素除非你已经有非常明确的方向比如你打算考研复试方向就是微服务那可以玩点花的否则毕设技术栈求稳不求新。Spring Boot 2.x MyBatis-Plus MySQL Redis Vue或Thymeleaf这个组合是市面上绝大多数高校超市管理系统的标配也几乎是毕设项目的“安全牌”。原因不复杂。第一Spring Boot极大简化了SSM时代的配置地狱。以前用Spring Spring MVC MyBatis要写一堆XML配置一个数据源配置写错了能折腾一整晚。Spring Boot通过自动配置和约定优于配置让开发者把精力放在业务代码上而不是配置文件的拼接上。我当年给一个学弟调一个老项目光Spring和MyBatis的版本兼容问题就来来回回弄了两天换成Spring Boot之后同样功能两天就做完了。第二Spring Boot生态下的第三方整合非常成熟。做权限控制有Spring Security和JWT做接口文档有Knife4j/Swagger做缓存有Redis Starter做持久层有MyBatis-Plus的代码生成器。这些东西每一样都能在论文里单独开一节对扩充毕设内容很有帮助。第三Java本身在高校教学中的地位决定了它是最稳妥的选择。几乎每个学校的计算机专业都会开Java方向的课程指导老师对Spring Boot的熟悉程度普遍很高答辩时你讲的技术点老师都能接上话。至于前端如果你有足够的时间我建议用Vue Element UI做一个独立的前端项目前后端完全分离。这样不仅简历上好看论文里也能画出清晰的前后端交互架构图。如果时间特别紧用Thymeleaf模板引擎直接渲染页面也不是不能用但那样在答辩时容易被问“前后端如何解耦”这类问题。2.3 系统架构设计分层和模块划分我做这个项目时采用的是经典的三层架构外加一个前端展示层表现层Vue单页应用或Thymeleaf模板页面负责页面渲染、表单校验、与后端RESTful API进行数据交互。这一层不包含任何业务逻辑只做数据展示和用户交互。业务层Spring Boot Service层负责处理具体的业务规则比如库存不足不允许下单、普通会员与VIP会员折扣不同、退货时恢复库存并同步积分等。持久层MyBatis-Plus的Mapper层内置了很多单表操作的通用方法使得你不需要为每个实体写一套重复的CRUD代码。复杂查询用注解SQL或XML文件搞定。这三层之外还有横切关注点Spring Security负责登录认证和接口鉴权拦截器负责操作日志记录全局异常处理器负责把异常统一转换成前端可读的JSON格式。模块上我按照业务域拆成七个模块系统管理、商品管理、库存管理、采购管理、销售管理、会员管理、统计分析。每个模块对应一组controller、service、mapper在包结构上非常清晰——这不仅是代码上有条理更重要的是对你写论文的“系统设计”章节特别有利。你画架构图的时候直接按模块画每一个模块下面又能展开讲表结构和接口论文内容自然就充实了。3. 核心需求拆解与数据库设计3.1 角色权限模型是怎么设计的高校超市系统里权限设计是第一个要认真对待的功能。不同角色能做的事情差异非常大收银员能开单结算但不能修改商品价格店长能看到营业报表但不能删除历史数据系统管理员一般不参与日常收银业务但拥有全部权限。我的做法是采用RBAC基于角色的访问控制模型建立三张核心表用户表、角色表、用户-角色关联表。对于更细粒度的权限控制比如店长能看到但收银员不能看的报表菜单可以用菜单表和角色-菜单关联表来配置。但作为毕设项目做到用户-角色-菜单三层就够了不用上到按钮级的权限控制否则工作量会陡增而且答辩时如果讲不清楚反而扣分。Spring Security在配置上要注意一个点接口路径的放行策略。登录接口、注册接口、商品浏览接口如果支持游客浏览要放行管理端的接口需要登录后才能访问涉及订单、库存的接口还要进一步校验角色。我在配置时用的是注解方式PreAuthorize比如“hasRole(ADMIN)”或者“hasAnyRole(ADMIN,MANAGER)”比全部写在SecurityConfig里直观得多也方便你单独看某个Controller时就知道它的访问权限。3.2 数据库表结构10张表和2条核心链路数据库设计这部分是答辩时的重头戏。如果表设计混乱、字段缺失后面的代码写得再好也很难让老师满意。我设计的表结构大致是这样的用户表sys_user主键、账号、加密后的密码、姓名、手机号、角色ID、状态启用/禁用、创建时间。角色表sys_role角色ID、角色名称、角色编码、描述。商品分类表category分类ID、分类名称、父级ID支持二级分类、排序。商品表product商品ID、商品条码、商品名称、所属分类ID、品牌、规格、单位、进货价、零售价、会员价、当前库存量、库存预警阈值、商品图片URL、状态。库存流水表stock_record流水ID、商品ID、变动类型入库/出库/盘点调整/退货入库、变动数量、变动前库存、变动后库存、关联订单号或入库单号、操作人、操作时间。采购单表purchase_order单号、供应商、采购总金额、审批状态、审批人、审批时间、创建人、创建时间。采购单明细表purchase_order_item明细ID、采购单号、商品ID、采购数量、采购单价、小计金额。订单表sale_order订单号、收银员ID、会员ID可空、商品总数量、应付金额、实付金额、支付方式、下单时间。订单明细表sale_order_item明细ID、订单号、商品ID、销售单价、销售数量、小计金额。会员表member会员ID、姓名、手机号、卡号、等级普通/VIP、积分余额、累计消费金额、创建时间。为什么要单独拆订单表和订单明细表因为一张订单会包含多件商品如果只建一张表把多个商品塞进去字段就滥用了。拆开之后查询某笔订单只需要拿订单号去明细表里取记录就行统计商品销量也直接在明细表上按商品ID分组求和。这就是经典的“主表子表”设计。两条核心链路在表结构上的体现也很清晰采购链路采购单表审批状态变化→ 验货入库 → 更新商品表的当前库存量 → 插入库存流水表。销售链路订单表结算→ 扣减商品表库存 → 插入库存流水表 → 若有会员更新会员表的积分和累计消费金额。你去看很多毕设项目的库表设计最大的问题就是缺了库存流水表或操作日志表。没有流水表库存变化就查不到依据没有日志表出问题后没法追踪操作记录。老师一眼就能看出这是“为了做系统而做系统”根本没有从真实业务的视角考虑过数据留痕的问题。3.3 核心字段的设计细节与思考有几个字段设计上的小细节我觉得很值得拿出来说一下。第一个是金额字段的存储类型。我见过有同学把金额设计成Double或Float这其实是个坑。浮点数在计算机里有精度问题比如0.1加0.2不等于0.3这在涉及金额计算时会带来非常尴尬的误差——账目上多一分钱少一分钱对超市来说是大事。正确做法是使用BigDecimal或者数据库里用decimal(10,2)类型。Java实体类里也全部用BigDecimal映射。第二个是订单号的生成规则。很多新手喜欢直接让数据库自增主键当订单号用但订单号暴露在收银小票上一方面连续的自增ID容易被人猜出业务量另一方面在多表关联和后续对接时也不是很专业。我用的规则是前缀比如POS表示销售订单 年月日时分秒 三位随机数。比如“POS20250514203015512”一眼就能看出订单产生的时间也不会重复。第三个是删除策略。商品分类、商品这类基础数据我用的不是物理删除而是逻辑删除。MyBatis-Plus中只要在实体类字段上加上TableLogic注解删除操作就会自动转化成UPDATE语句置一个deleted标记字段为1。别看这个小细节不起眼它避免了用户删掉某个商品分类导致该分类下历史订单明细查询不到的不良后果。物理删除会让你追悔莫及。4. 前端设计思路与交互流程4.1 页面结构和用户操作闭环前端页面上我按角色区分为两个入口对整体体验影响很大。管理端整体布局是左侧菜单栏加右侧内容区。菜单按模块划分工作台、商品管理、分类管理、采购管理、库存管理、订单管理、会员管理、统计分析、系统管理。商品管理里分商品列表和商品上下架订单管理里分当日订单和历史订单查询统计分析放几个ECharts图表展示营业额走势、商品销售排行。管理工作流要形成一个操作闭环。举一个采购入库的例子店长登录后打开采购管理→点击新建采购单→选择供应商、选择商品、填数量、确认提交→此时采购单状态变成“待审批”→店长自己审批或者由上级审批通过后状态变成“已审批”→仓库人员拿着单子去收货验货确认实际到货数量无误后点击“确认入库”→系统扣减采购单状态为“已完成”同时商品库存自动增加生成入库流水。每一步状态清晰可见不会出现数据对不上的情况。收银端收银端页面要做得很简洁因为真实场景里收银员操作速度要求比较高。一般就几个核心元素商品搜索框支持扫码抢也支持手动输入条码或拼音首字母、当前购物车列表、合计金额、收款按钮、会员识别输入框。页面做到下单流程不超过三步录入/扫码商品→可选录入会员手机号→点击结算。4.2 前后端接口对接和异常处理前端和后端的交互本质上是请求和响应的约定。我统一封装了一个Result对象结构为代码200成功、500失败、401未登录、消息、数据。前端在axios的响应拦截器里统一判断code不是200就弹出错误提示并给出后端返回的message这样就不至于出现一堆为了遍历数据而写的if-else逻辑。交互过程中最容易出问题的点是权限控制与路由配合。前端路由要根据用户拥有的菜单动态生成不能让用户通过手动输入URL绕过菜单权限直接访问没有权限的页面。后端每个接口有权限校验但前端路由拦截也必须在两层都做双保险。异常处理这块我要重点吐槽一下很多毕设项目的通病后端一报错就把整个堆栈信息返回给前端页面直接显示英文异常堆栈。作为面向用户的管理系统这是灾难级的体验。我在全局异常处理器里做了统一转换业务异常返回类似“库存不足当前仅剩3件”这样的友好提示未知异常统一返回“系统繁忙请稍后重试”并把真正的堆栈打到日志文件里方便排查。论文里写“设计了全局异常处理机制”将来面试时还能被追问“为什么不用默认异常页面”这些都是加分点。4.3 缓存策略Redis用在哪里才不算画蛇添足很多同学做毕设喜欢堆技术栈什么东西火就往上加。最典型的就是明明系统本身还没到并发瓶颈硬要引入消息队列或微服务。答辩时老师问一句“你这个系统为什么要用Redis”答不上来就很尴尬。在这个项目里Redis的使用场景我认为有两个是合理的、讲得通的。第一个场景是验证码和短信验证码的存储。登录时生成随机验证码存到Redis里设置60秒过期。利用Redis的自动过期机制不需要单独写一个定时任务去清理数据库里的过期验证码非常自然。第二个场景是热门商品信息的缓存。高校超市里像饮料、零食这类高频浏览的商品被查询的次数非常多。我们可以在Redis里维护一个热门商品列表点击进入商品详情页时优先从缓存读取缓存没有再去查数据库查完再回填。缓存的过期时间设置为10分钟既能减轻数据库压力也保证了商品价格变动的时效性不会延迟太久。至于Session还是JWT的问题我选的是JWT。无状态认证的好处是服务器不需要保存登录状态在集群部署时不需要考虑Session共享的问题。当然也有缺点——JWT过期时间设置比较难拿捏太短了用户老要重新登录太长了又有安全隐患。我的做法是设置两小时过期前端在axios拦截器里发现401就跳转登录页。5. 核心模块实现与代码走读5.1 商品管理模块从SPU到SKU的经典模型商品管理是超市系统的地基。我设计时采用了SPU标准产品单元和SKU库存量单位的思路。有些同学可能不太熟悉这两个概念我打个比方一箱可口可乐是SPU但“可口可乐330ml罐装*12一箱”和“可口可乐500ml瓶装单瓶”就是SKU。高校超市的SKU属性主要是规格如500ml、1L、包装单位瓶、箱和口味。在代码实现上product表实际上对应的是SKU级别也就是一条记录就是一个具体的规格商品。商品列表页面默认按分类展示支持按名称和条码搜索条码在超市场景非常重要扫码收银全指望它。商品新增时支持批量导入Excel这个功能很实用——初始化和大批量上架都很快不需要一条条录。一个重要的业务规则是商品状态的自动联动。当库存数量低于预警阈值商品状态自动标记为“库存不足”并在首页工作台产生一条提醒。当库存为0时状态变为“缺货”收银端输入该商品时直接弹提示不可销售。实现逻辑落在service层的入库、出库方法里每次变动库存后就检查一次阈值而不是依赖定时任务去扫描。5.2 库存管理模块事务控制是生命线库存管理是超市系统中技术含量最高、最容易丢分的模块。假如两个收银员同时出售最后一件同一商品两个请求同时进来都读到库存为1都判断满足库存都去扣减库存结果就是库存变成负数系统在并发场景下直接崩了。这就是超卖问题在电商领域高频出现。解决办法有几种我采用的是最稳妥也最容易解释的方案数据库行锁 事务。在扣库存的SQL语句里加上条件“UPDATE product SET stock stock - #{count} WHERE id #{productId} AND stock #{count}”并且把整个“校验库存→生成订单→扣减库存→记录流水”的过程放在一个事务方法里。这样数据库自己就保证了不会超卖不需要我们在Java代码里做复杂的并发控制。事务的回滚机制也很关键。场景是这样的扣库存成功了但生成订单明细时失败了如果没有事务数据就变得不一致——库存扣了但订单没生成。Spring的Transactional注解轻松解决方法中任何一步抛出运行时异常整个事务回滚要么全成功要么全失败。我在写Service方法时入库、出库、退货三个核心方法都加上了事务注解这是答辩时就算追问到源码层面也站得住的点。5.3 会员与积分简单的业务也有设计讲究会员表看起来很简单无非就是记录姓名、手机号、积分。但落在业务逻辑里有两个规则要提前想清楚。第一个是会员折扣的叠加规则。普通会员98折VIP会员95折但是如果商品正在做促销比如第二件半价那折扣怎么算我的约定是促销商品不参与会员折扣非促销商品按会员等级折扣结算。规则必须写在明面上并在代码里实现了否则收银员操作时就会很混乱。第二个是积分过期和抵扣。积分设计上参考了真实商场的做法消费1元累计1积分积分的兑换规则是100积分抵扣1元单笔订单最高抵扣10元。这样设计的好处是让积分真正具备业务价值而不是一个纯装饰字段。每天凌晨用定时任务把积分低于某个阈值或者超过180天未活跃用户的积分做清零用Spring的Scheduled注解就可以实现。这里的实现细节主要是积分流水记录也就是每次积分变动都写一条流水表不能在会员表上只更新一个总数字。否则用户问“我积分怎么少了”系统根本答不上来。5.4 统计分析模块ECharts展示数据是答辩现场的大杀器统计分析模块在我的经验里往往是最能让答辩老师眼前一亮的。因为一个管理系统如果只有表格增删改查视觉上和完成度上都显得单薄。当你在投影仪上放出一个按小时统计的营业额折线图、一个商品销售排行条形图、一个分类占比饼图时整个系统的专业性瞬间上一个台阶。后端统计接口的核心就是SQL的聚合查询。举一个例子统计最近7天每天的营业额SQL大致是“SELECT DATE(create_time) AS day, SUM(actual_amount) AS total FROM sale_order WHERE create_time #{startTime} GROUP BY DATE(create_time) ORDER BY day”。这种写法对应到MyBatis里用注解SQL或在XML里写都行。前端拿到结果后直接封装成ECharts需要的data数组。还有一个比较实用的统计是滞销商品分析。用“最后销售时间距今超过90天”这个条件从商品表里筛选出来店长可以根据这份名单减少这类商品的采购量或者做清仓促销。我发现很多毕设项目都没有这个功能但真实超市反而很关心滞销品占比所以加上之后既好实现又显得你懂行业。6. 常见问题与排查技巧实录6.1 登录认证踩坑JWT过期和跨域问题这个项目开发过程中最常见的坑集中在登录认证和前后端联调。第一个问题是JWT拦截器放行策略没配好导致登录接口本身也被拦截用户打开页面就报“未登录”然后陷入无限跳转登录页的死循环。排查方式其实很简单加一个HandlerInterceptor在preHandle里面写日志打印出当前请求的URI、是否放行、当前用户ID就能很快定位问题。第二个高频问题是跨域。Vue开发服务器默认跑在8080端口后端跑在9090端口前端发请求必然跨域。其实解决方案就是配置CORS跨域过滤器允许指定来源的请求携带凭证。需要注意的是如果以后要部署到生产环境跨域的来源不能配成“*”否则携带着Cookie的请求会被浏览器安全策略拦截掉。6.2 数据库连接不上和编码问题很多同学在配置数据库时遇到“Communications link failure”报错第一反应都是去改配置但实际上90%的原因就是MySQL服务没启动。在Windows上检查服务管理器在Linux上检查systemctl status mysqld比反复检查配置文件有效得多。另外一个很容易被忽视的坑是MySQL的时区问题。在配置数据库连接字符串时如果URL里不加上serverTimezoneAsia/Shanghai高版本的MySQL驱动在建立连接时就会报“The server time zone value is unrecognized”错误。这个问题在Spring Boot 2.x配MySQL 8.x时特别常见几乎所有初学者都会踩一次。还有中文乱码问题。我遇到的情况是连接地址没指定characterEncodingutf8导致商品名称显示为问号。解决思路是统一字符集数据库表使用utf8mb4连接URL指定characterEncodingutf8后端代码里文件编码设为UTF-8。三个环节都对齐后再没出现过乱码。6.3 部署上线档口从开发环境到生产环境的适配毕设答辩时可能需要在老师的电脑或服务器上演示提前做好部署适配非常重要。开发环境的数据库地址可能是localhost但部署到服务器之后就要改成服务器的IP。我建议把这些配置放在Spring Boot的application.yml中利用多环境配置dev/prod来切换。还有一个小技巧不要把数据库账号密码直接硬编码在配置文件中尤其是个人的真实密码。虽然毕设项目不涉及生产安全但养成用环境变量注入的习惯对将来工作有很大帮助。如果演示环境没有安装MySQL可以在项目里加上一个SQL脚本在启动时自动执行建库建表和初始化数据。这样可以保证无论在谁的电脑上跑只要装了JDK一个jar包打天下。7. 项目答辩与展示要点7.1 演示路线怎么安排答辩演示千万别一上来就点开一堆页面随便点给老师的信息密度太低。我建议提前设计一条演示主线大概5-8分钟按照“登录→新建商品→采购入库→前台收银→会员积分→数据报表”的顺序完整走一遍。这条路线恰好覆盖了整个系统的核心业务闭环每一步讲解时都结合业务场景交代一下背景这是超市到货场景、这是高峰期收银场景、这是店长查看经营情况场景。演示过程中有一个细节非常关键操作前先说出你要演示什么再动手。比如“下面我演示一个库存不足时收银员会看到什么”然后先把某种商品的库存调到0再去收银端下单让老师看到系统的拦截提示。这种“预期管理”的方式会让演示的节奏立起来。7.2 答辩被问高频问题怎么答根据我的经验老师在答辩阶段最常追着问的是这几类问题“为什么用Spring Boot而不用SSH/SSM”答法思路Spring Boot简化了配置自动装配特性让我们聚焦业务开发同时它的生态成熟度和社区活跃度高遇到问题容易找到解决方案。“数据库为什么这么设计”答法思路从业务出发订单主表明细表拆分是为了支持一对多库存流水表是为了追踪库存变化历史逻辑删除是为了保护历史数据可追溯。只要能从业务合理性解释表设计这个问题基本就能化于无形。“你的系统有哪些安全性措施”答法思路密码加密存储BCrypt、JWT鉴权、接口权限控制、防止SQL注入使用MyBatis预编译语句、异常信息不直接暴露给前端。这些都是实打实做了的东西如实讲就行。“如何扩展成多校区超市”答法思路在商品表和订单表增加校区字段统计和分析时按校区维度做聚合。如果更进一步可以引入数据权限让不同校区的管理员只能看本校区数据。这个问题答出来会显得你很有全局视野。7.3 论文撰写的加分技巧毕设论文的亮点往往不在于篇幅多长而在于有没有真实的思考痕迹。我给过不少学弟学妹的建议是在论文里专门写一节“系统难点与解决方案”把在你真的开发中遇到过的卡点写进去——超卖问题的并发控制、金额精度用BigDecimal、JWT过期策略的设计权衡。这些内容不是抄来的是从你自己的开发日志里提炼的所以答辩时怎么被追问都不会慌乱。不过有一点要提醒不要为了显得高级在论文里写那些你根本没实现的技术比方说你用了消息队列但你根本没配过。答辩现场一旦被追问实现细节就会露馅。诚实和扎实永远是最大的加分项。8. 关于这个项目的一些大实话最后聊点掏心窝子的话。我见过太多人做毕设时把大量精力放在纠结技术选型上今天觉得Spring Boot太low想换Spring Cloud明天觉得MySQL太大众想换PostgreSQL结果一个星期过去了连用户登录功能都没做出来。对于毕业设计来说完成比完美重要得多。这套高校超市管理系统从需求分析到设计实现覆盖了Java Web开发的基本功Spring Boot自动配置、MyBatis持久层操作、RESTful API设计、RBAC权限模型、事务管理、缓存使用、前端Vue交互。把这些东西扎扎实实做出来并讲清楚毕业设计这一关就已经稳稳过了而且你简历上也能多一个“独立完成前后端分离项目”的经历。如果你正在做或者打算做这个题目我的建议是先花两天时间把数据库设计拿出来让身边有经验的人帮忙看一遍再开始写代码。表结构定好了后面的代码推进速度会非常快。别急着炫技先把主流程跑通再回头优化异常处理和安全性这才是毕设项目推进效率最高的路径。我个人在实际做这类项目时的体会是把那些不起眼的细节——订单号生成规则、库存流水记录、全局异常处理——踏踏实实做好反而比堆一堆高深技术词更能让老师在答辩打分时给你一个漂亮的成绩。
