每年到了毕设季后台私信被刷屏的永远是那几个问题springboot项目到底选什么题怎么做到既不会被代码量压垮又能在答辩时让老师觉得“这人不只是会抄”。乡镇卫生所医用物资进销存系统是我这几年给学弟学妹推荐得最多、也是实测最容易出成果的选题之一。别嫌它听起来“土”真正把业务捋清楚以后你会发现它把Spring Boot项目里最常见的那批坑全踩了一遍——库存、批次、效期、事务、定时任务、权限一个不落但每个点又都控制在毕设该有的深度。这篇文章我按自己完整落地这套系统的顺序来写从选题价值到技术选型、表结构设计、核心代码逻辑再到联调和答辩演示的细节全程都是实际跑过、被答辩老师问过之后沉淀下来的经验。只要你跟着走一遍这套系统不只是能跑通还能跑得漂亮。1. 乡镇卫生所医用物资进销存这个选题到底在解决什么1.1 一个真实场景里的物资管理困境先别急着打开IDEA先搞清楚你写的系统是给谁用、解决什么痛点。我调研过几个乡镇卫生所的真实情况大部分卫生所的物资管理还停在纸质出入库单加Excel表格并存的阶段。口罩、酒精、棉签、纱布、一次性注射器、慢性病常用药这些物资进货渠道杂、批次多有的带效期有的对存储环境有要求。入库时登记一次领用时再登记一次月底盘点全靠人工翻单子。效期临近的物资没人提醒经常是到期了才发现仓库里还有一整箱个别物资积压过期只能报废另一部分却断货医生开处方时只能临时跟患者说“这个药这两天没有”。这套系统要解决的就是这三个核心问题物资库存账目不清楚、效期管理靠人肉记忆、出入库追溯没有抓手。放在毕设语境下意味着你的系统必须有清晰的入库流程、出库流程、实时库存台账、效期预警再带上统计报表整个业务闭环就成立了。而且这属于“管理信息系统”大类天然适合Spring Boot这类成熟框架快速落地不需要死磕算法也不会被质疑“工作量不够”。1.2 “进销存”三个字在医疗场景下的特殊含义电商进销存和卫生所进销存差得不是一点半点。普通商品管理只需要管住“数量”医疗物资必须管住“批次”和“效期”。同一款医用口罩不同生产批次的进货日期、失效日期可能完全不同同一种药品厂家A和厂家B的规格、批准文号也可能不一样。如果你的库存表只存一个“库存总量”那系统的实用性会当场被答辩老师戳穿——过期批次没法单独锁定先进先出无法实现效期预警更是无从谈起。所以这个项目的核心锚点不是“增删改查”而是“批次库存”和“效期驱动”。入库时每一批物资都要记录生产日期、失效日期、批次号出库时按照效期最近先出的原则扣减库存看板按批次展开预警逻辑在每一笔入库和每日定时任务中同时触发。把这个逻辑想明白了你的数据库设计和业务代码会非常自然地围绕“批次”展开而不是做成一个通用CRUD架子。1.3 为什么这个选题是Spring Boot实践的理想载体Spring Boot好在哪约定大于配置、起步依赖、自动装配、内嵌容器、健康检查这些特性让它成为做管理系统的首发选择。但毕设选题不能只看框架好不好用还要看业务复杂度是不是刚好撑得起技术栈的展现空间。乡镇卫生所医用物资进销存系统的业务复杂度属于“中等偏上但不过度”模块数量够多传统三层结构能讲清楚事务场景存在比如出库扣减库存时必须同时更新批次库存和写入流水缓存和异步任务有发挥空间比如首页库存看板、效期预警定时任务权限控制也是刚需普通操作员、仓库管理员、系统管理员各看各的功能。这就意味着你不必硬上微服务、消息队列这类超出毕设需求的东西就能把Spring Boot的核心能力展示得很完整。对大多数同学来说把单体Spring Boot项目做到这个深度已经足够优秀而且大概率不用熬夜赶工。2. 技术栈选型Spring Boot版本和周边配套怎么定最稳2.1 Spring Boot版本选择先看环境再看求新2026年这个节点Spring Boot 3.x已经是绝对主流天然携带Jakarta EE命名空间、基于JDK17及以上运行。如果纯粹从新特性出发我会推荐3.x因为Spring Boot 3.2之后对虚拟线程、GraalVM的支持已经越来越成熟答辩时随口提一句“这个项目使用了Spring Boot 3的AOT友好特性”也能加分。但毕设有个很现实的约束学校机房、指导老师本机、演示用的笔记本JDK环境未必统一。我曾经见过一个学弟在电脑上用了Spring Boot 3.2到答辩现场才发现教室那台旧电脑只装了JDK8当场跑不起来。所以我的建议是如果你自己的主力电脑和演示环境都能保证JDK17直接上Spring Boot 3.x如果存在环境不可控因素Spring Boot 2.7.x配合JDK8反而是最稳妥的方案。代码层面两者的差异并没有想象中那么大课堂上学的那套Controller、Service、Mapper分层完全通用2.7在网络上资料更多踩坑时搜索引擎和AI能给出的答案也最丰富。2.2 周边配套持久层、鉴权、前端框架的合理搭配我用下来最顺手、也最适合复现给别人的一套搭配如下分类推荐选型理由持久层MyBatis-Plus配合Spring Boot 3选择对应版本CRUD代码少分页插件成熟代码生成器可以直接生成entity/mapper/service/controller鉴权Sa-Token 或 Spring Security JWTSa-Token上手极快适合毕设想展示基本功就用Spring Security前端Vue 3 Element Plus Axios组件丰富、后台管理型页面开发效率高、中文文档完善数据库MySQL 8.0免费、资料多、运维简单接口调试Apifox 或 Postman自测和答辩演示接口都用得上报表图表ECharts EasyExcel图表展示库存趋势导出Excel给“月报”功能用不建议为了追求“高大全”去引入Redis、RabbitMQ之类的东西。这个项目的实时性要求没那么高缓存预热、异步削峰都属于自己给自己加戏。如果要体现缓存思想用一个本地缓存Caffeine配在预警数据上或者用Spring Cache注解标注热点查询已经足够在答辩时讲出所以然了。2.3 为什么前端要单独拆出来而不是用模板引擎很多老教程还在用Thymeleaf或者JSP写页面Spring Boot确实也支持。但我的建议是只要你有基础前端用Vue3单独做前后端分离开发。原因有三点第一分离式前后端能清晰展示RESTful API设计能力这是答辩加分项第二Vue3加Element Plus做后台管理界面颜值和交互比服务端渲染高一截第三项目的演示方式更灵活前端起一个端口后端起一个端口接口对接过程中遇到的问题本身就是你最好的答辩素材。要注意的是前后端分离意味着跨域问题会真的出现而且会出现在你联调的第一天。在Spring Boot里写一个WebMvcConfigurer配置类允许开发环境的跨域请求同时把前端访问后端的baseURL统一配置到.env文件里。这个属于必踩项后文我会专门讲。3. 六大业务模块拆解进销存系统远不止增删改查3.1 基础档案与用户权限先搭好数据地基系统的地基是基础档案模块包括物资信息管理、物资分类管理、供应商管理、科室管理、系统用户管理。物资信息表承载的是“静态属性”物资编码、名称、分类、规格型号、生产厂家、批准文号/注册证号、单位箱、瓶、盒、支、默认库存上限和下限。注意“注册证号”这个字段是医疗物资特有的普通的进销存系统根本不会涉及它的存在能让老师一眼看出你理解业务场景。供应商管理记录供货商名称、联系人、联系方式、供货资质编号。乡镇卫生所通常有固定的几家供应商比如医药公司、医疗器械公司偶尔也有上级医院调拨所以供应商类型字段建议设成枚举采购、调拨、捐赠。用户权限这块不需要做复杂的RBAC模型三种角色就够了系统管理员可以配置基础档案和用户仓库管理员负责入库、出库、盘点、预警处理普通医护人员只能查询库存和发起领用申请。Sa-Token或Spring Security都能轻松实现核心是要在拦截器或者过滤器里把需要登录的接口保护起来菜单路由根据角色动态生成。3.2 入库业务采购入库、调拨入库与入库审核入库模块是这个系统的“数据入口”做好了后面的库存台账才会准。入库流程分两条线先建入库单再审核生效。入库单包含单号、入库类型采购入库/调拨入库/期初录入、供应商、入库日期、经办人、备注入库明细逐行记录物资、批次号、生产日期、失效日期、数量、单价、金额。为什么要把“建单”和“审核”拆开真实业务里入库数据录错了需要改正如果一保存就生效改错就得冲销重做。设计成两阶段后录入阶段可以反复修改审核通过才真正更新库存并写流水。这个流程体现出的事务意识很有价值答辩时被问“如果审核时发现明细错了怎么办”你能直接回答“审核操作会加状态校验非待审核状态的单据不允许编辑审核后需要做红冲入库单来冲销”。入库审核触发的事务动作有三个更新或新增批次库存写入库存流水如果某批次效期少于预警阈值同时生成一条预警记录。这样效期预警不只是依赖定时任务入库当下就能暴露高风险物资。3.3 出库业务科室领用、报废出库与先进先出出库模块对应医疗物资的“消耗”环节。乡镇卫生所里面最常见的是科室领用——内科领50只口罩外科领20支体温计门诊领一批慢性病常用药也会有报损出库效期过了或者破损的物资需要走报废流程。出库单的结构与入库单对应单号、出库类型科室领用/报损出库/退货出库、领用科室、领用人、出库日期、经办人。出库明细不只是填“物资数量”还必须指定从哪个批次扣减这是整个系统业务逻辑最核心的一步。在真实业务中效期最近的批次要优先出库这就是所谓“先进先出、近效期先出”。实现时我在出库逻辑里做了两步先查该物资所有正库存的批次按失效日期升序排序然后按顺序逐批扣减如果一个批次不够自动扣下一个批次直到满足出库数量为止。第一次写这个逻辑很容易只想到“扣总数”忽略“扣批次”吃过一次亏以后我专门把这段逻辑写成了单独的服务方法单元测试里用了三组不同效期的测试数据验证。3.4 库存台账批次库存、盘点与调拨库存台账是整个系统的“账本”但不是一张简单的material_id total_quantity表。核心库存表按“物资ID批次号失效日期”这个粒度来存每一行代表某一个批次的当前可用库存、已锁定库存、库存状态正常/已过期/已冻结。这样设计的好处有三点效期可以独立预警出库时可以直接按批次排序扣减某个批次出问题可以单独冻结不影响其他批次。盘点功能是很多毕设容易忽略的模块但对卫生所来说非常日常。每个月需要把实物库存和系统台账核对一遍。盘点单设计成选择盘点物资 → 系统列出账面数量 → 手工录入实盘数量 → 提交后自动生成盘盈或盘亏调整单 → 系统库存按调整后的数量修正。盘盈盘亏同样要写库存流水流水原因标记为“盘点调整”保持整个追溯链完整。调拨模块在一个卫生所里用得不多但如果上级医院往下面调拨物资就需要“调拨入库”和“调拨出库”配合处理。我的建议是把它合并进出库和入库的类型里通过“调拨出库单”和“调拨入库单”成对出现来体现闭环没必要单独做一个复杂模块。3.5 预警中心效期预警与库存上下限预警预警中心是整个系统最有“医疗特色”、也是最容易讲出亮点的地方。效期预警采用分级策略失效日期在3个月以内的物资标记为红色预警3到6个月内为橙色预警6到12个月内为黄色预警。不同类型的卫生所可以配置不同阈值所以我把预警阈值做成了系统参数表而不是写死在代码里。库存上下限预警则简单直接当前可用库存低于物资档案里设置的最低库存时生成“库存不足”预警高于最高库存时生成“库存积压”预警。这个功能不只是让首页列表好看真正的价值是在预警处理闭环上管理员看到预警 → 处理要么补货要么调整库存上下限 → 预警状态更新为已处理。有了这个状态流转模块的完整性就出来了。3.6 统计报表与操作日志答辩老师最喜欢问的部分统计报表做三张就够月入库统计、月出库统计、库存周转情况。月度入库统计按物资分类和供应商维度透视月度出库统计按科室和物资维度透视库存周转可以用ECharts画一个近6个月入库出库趋势的折线图。做报表不需要复杂的SQL优化但要注意把VO层处理好返回给前端的是图表友好的数据结构而不是原始表数据拼JSON。操作日志模块很重要但也很容易被忽略。管理员审核、盘点调整、预警处理这类关键操作必须记录操作人、操作时间、操作类型、操作前后的数据变化。答辩时如果老师问“你系统怎么保证数据安全审计”操作日志就是最直接的答案。我用Spring AOP加自定义注解OperationLog来实现方法上打一个注解就能自动记录代码侵入很小而且实现起来不复杂属于性价比极高的功能。4. 数据库表设计重头戏批次、效期、流水与追溯4.1 表结构概览与整体设计原则这个项目我实际落地用了12张表全部围绕“批次账”和“流水账”这两个核心概念展开。主数据表sys_usermed_suppliermed_departmentmed_material_categorymed_material。单据表med_inbound_order入库单、med_inbound_item入库明细、med_outbound_order出库单、med_outbound_item出库明细。库存与流水表med_stock_batch批次库存、med_stock_flow库存流水。辅助表med_warning预警记录、sys_config系统参数存预警天数阈值、sys_operation_log操作日志。设计原则就一句话凡是涉及数量变化的地方都必须在一条不可回滚的流水里留下记录。库存表可以因为冲销、盘点而变化但流水表只追加、不修改、不删除。这也是跟普通CRUD项目区分开的关键设计。4.2 核心表字段细节不只是id和name以med_stock_batch批次库存表为例关键字段包括字段名类型说明idbigint主键material_idbigint关联物资档案batch_novarchar(64)生产批次号production_datedate生产日期expire_datedate失效日期核心判断依据quantitydecimal(12,3)当前批次可用库存locked_quantitydecimal(12,3)已锁定未出库数量预留扩展statustinyint0正常1已过期2已冻结created_timedatetime首次入库时间物资表的字段里我特别提醒加一个“库存单位”和“规格”分开的字段设计比如“医用外科口罩”规格是“10只/包”单位是“包”这样入库填“100包”出库领用才能精确到“5包”。如果混在一起填“100只”后面统计口径会乱。med_material里还要有min_stock和max_stock两个字段库存预警就靠它们在SQL里做条件查询。4.3 库存流水表让每一笔变化都可追溯med_stock_flow库存流水表字段包括material_id、batch_no、change_type入库/出库/盘点调整/冲销、change_quantity正数表示入负数表示出、before_quantity、after_quantity、related_order_no关联单据号、created_time、created_by。这里有一个容易被忽略的细节before_quantity和after_quantity要存下来。如果只存“本次变化数量”出库后被冲销或者月底对账时发现账面数量对不上你就完全不知道每个时刻的库存余额是怎么演变的。把变化前和变化后的快照留在流水里任何时点的库存都能反推校验这也是和财务上的“总账明细账”思维一脉相承的。流水表的索引设计我有两条经验一是(material_id, batch_no)联合索引因为库存扣减和统计报表都会按这两个字段定位二是(created_time)单独索引时间范围查询和历史趋势图需要它。其他字段不要乱加索引尤其是change_type这种低区分度字段加了也白加还影响写入速度。4.4 单据与明细的关联一主多从的标准范式入库单和入库明细是一对多关系出库单和出库明细同理。表结构上是外键order_id关联主表明细表自己记录material_id、batch_no、quantity、price和amount。这样做的好处是单据表负责记录业务头部信息明细表负责逐行记录物资详情统计某笔单据涉及多少种物资时直接按order_id关联查询即可。需要提醒的是单据明细里一定要冗余material_name和batch_no等关键描述性字段而不是都靠join关联去查。虽然违反了一点“规范化”直觉但实际查询时会少非常多麻烦尤其列表页要展示入库历史时少join一张表性能差别很明显。这张明细表的数据量也不大冗余字段的代价可以忽略。5. 核心业务逻辑落地入库校验、出库扣减与定时预警5.1 入库审核逻辑事务必须覆盖三个动作入库审核接口是系统里第一个不能出错的接口。我实现的事务流程是这样的根据入库单ID加载单据头校验状态必须为“待审核”。遍历入库明细列表逐个校验物资ID存在且启用批次号不能为空失效日期必须晚于当前日期数量必须大于零。对每个明细执行“写入批次库存”操作如果该物资批次号在med_stock_batch中已有记录则库存数量累加不存在则新增一条批次记录。写med_stock_flow流水记录变化前后快照。检查该批次的失效日期如果落在预警阈值内插入预警记录。全部明细处理成功后把入库单状态置为“已审核”任何一步失败整个事务回滚。第3步是关键因为同一批号可能在之前已有部分入库直接insert会出主键冲突。我用MyBatis-Plus的selectOne查一次存在就update不存在就insert。虽然多一次查询但逻辑清晰而且库存更新并发量不高完全够用。5.2 出库扣减逻辑按失效日期升序逐批减出库审核的逻辑比入库更繁琐因为要处理“一单出库涉及多个批次”的情况。核心方法是先分组再逐批扣减按出库明细逐行处理每行记录material_id和quantity。查询该物资全部有效批次WHERE material_id ? AND status 0 AND quantity 0 ORDER BY expire_date ASC, batch_no ASC。用Java循环遍历批次列表当前批次库存够就整批扣不够就扣掉一部分再取下一批直到累计扣减数量等于出库数量。每扣一个批次都更新med_stock_batch.quantity并写一条med_stock_flow流水。如果所有批次库存合计都不够出库数量直接抛出业务异常事务回滚提示“库存不足”。这段逻辑里最容易出问题的点是“中途库存不足回滚”。比如第一行明细扣减成功、第二行明细发现库存不够此时如果第5步只是简单抛异常前面第一行已经扣掉的库存就会被脏数据留在库里吗不会前提是你把整个出库审核方法加了Transactional(rollbackFor Exception.class)Spring事务默认只对运行时异常回滚我验过多次业务异常一定要自定义RuntimeException子类否则事务不会回滚。5.3 效期预警的定时任务与启动检查定时预警我用Spring Boot自带的Scheduled注解实现没有引入Quartz因为单机定时任务在这个场景下完全够用。预警策略写成一个单独的Service方法核心逻辑大致是Scheduled(cron 0 30 8 * * ?) public void executeDailyWarningCheck() { // 1. 查出所有失效日期在阈值天数以内的非过期批次 // 2. 按预警级别生成或更新 med_warning 记录 // 3. 批量更新物资库存状态过期批次置为 status1 }生效阈值从sys_config读取默认例如3个月红色、6个月橙色、12个月黄色。定时任务每天8点30分跑一次重点是把当天过期的批次自动标记为“已过期”同时生成对应的预警记录。这里有两点设计上的小心思一是预警记录在生成前先查重避免同一批次每天重复插入一条二是预警状态要支持“已处理”管理员看到过期的批次后在页面上做“报废出库”操作把它从可用库存里清掉预警单随之关闭。我还额外加了一个ApplicationRunner实现类在Spring Boot启动完成后立刻执行一次同样的预警检查。原因是如果系统很久没开机定时任务也一直没跑过期批次就没人标记了。启动即检查能保证每次打开系统看到的库存状态都是新鲜的。这个细节答辩时讲出来比“我会用定时任务”有说服力得多。5.4 前端预警展示轮询就够别硬上WebSocket有同学一提到“实时预警”就想用WebSocket。我的建议是这个项目场景下用轮询就够了不要为了技术炫技引入复杂度。卫生所使用者打开系统页面看到预警数据更新最多延迟几分钟就可以接受根本没有毫秒级推送需求。前端实现方式库存看板页面用setInterval每60秒调用一次预警查询接口拿到数据后刷新预警列表和图标上的数字角标。过程中要注意页面销毁时及时clearInterval避免路由切换后定时器泄漏。如果哪天真想升级也只需要把轮询换成WebSocket推送后端加一个WebSocketConfig在预警Service里主动推送消息即可前端保留监听逻辑就行两边都解耦。6. 从零到可演示落地顺序、踩坑汇总与答辩加分细节6.1 开发顺序建议先骨架、再核心、后包装很多同学拿到毕设题目第一反应是先把所有页面画出来这是最浪费时间的方式。我建议按下面这个顺序推进用Spring Initializr生成工程骨架确认依赖能拉下来、启动类能跑起来。建好MySQL数据库和全部表结构这一步要慢、要细表结构错了后面全是返工。用MyBatis-Plus代码生成器生成entity、mapper、service、controller拿到一套能跑的基础CRUD。先实现基础档案模块物资分类、物资档案、供应商、科室。因为后面所有单据都要选物资和供应商。实现入库模块和出库模块联调库存台账把“入库加库存、出库减库存、流水留痕”这条主链路跑通。实现盘点、预警、报表、操作日志、权限控制这些进阶模块。最后统一做前端页面美化、菜单权限、演示数据填充。按这个顺序前两步完成后第三步到第五步基本一周内就能完成后面的时间全部留给优化和应对答辩提问节奏会舒服很多。6.2 联调阶段必须避开的五个坑第一个坑是LocalDateTime序列化格式问题。Spring Boot默认序列化LocalDateTime会输出带T的ISO格式前端直接显示会非常难看。解决办法是在application.yml里统一配置Jackson的日期格式spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT8第二个坑是跨域问题。前后端分离项目前端访问接口大概率会被浏览器拦截。写一个配置类实现WebMvcConfigurer的addCorsMappings允许前端开发地址的跨域请求。注意不要直接写成allowedOrigins(*)因为后面如果要带Cookie会出问题精确配置前端地址更稳妥。第三个坑是MyBatis-Plus的字段自动填充。created_time、updated_time如果希望自动填值可以用TableField(fill FieldFill.INSERT)和MetaObjectHandler统一处理不要在每个Service里手工set时间代码会很脏而且容易漏。第四个坑是分页查询的total不准。MyBatis-Plus分页插件必须配置PaginationInnerInterceptor否则selectPage返回的total是0前端分页组件就会表现得很诡异。这个配置放在MybatisPlusConfig类里漏掉的人非常多。第五个坑是使用关系映射时避免懒加载报错。如果用了MyBatis-Plus的TableField(exist false)来做关联查询对象要注意前端可能直接拿到空字段。我的实践是能不用就不要在entity里做复杂关联查询时单独写VO类用selectVoList或者手动组装虽然代码多几行但可控性高不受懒加载会话关闭影响。6.3 答辩演示的数据编排和讲法演示数据是答辩环节最容易拉开差距的地方。我的建议是在正式答辩前把系统里的数据重置一遍按下面的节奏走准备8到10种物资覆盖普通耗材口罩、棉签、效期敏感药品胰岛素、抗生素、器械血压计、体温计三类。预先给某种物资比如某批次口罩设置一个7天后失效的效期数据让它在预警看板上显示红色作为演示定时预警的素材。演示流程从“采购入库”开始录单审核后切到库存台账找到刚入库的物资展开批次信息展示“两个仓库批次同时存在”的效果。接着做科室领用出库录入数量超过较小批次库存让系统自动从下一个批次继续扣减此时展示批次列表的变化。切到流水页展示刚才那笔出库对应的流水记录强调“每一笔变化都有前值后值快照”的设计。最后打开首页看板展示月度出入库趋势图、库存预警数量重点讲预警数据的来源和处理流程。讲的时候不要照着代码念而要用“为什么这样设计”的叙事逻辑。比如被问到“为什么出库要按批次扣”你可以直接说如果不按批次就无法实现近效期先出也无法锁定某个过期批次单独报废销毁这是医疗物资管理与普通商品管理最本质的区别。这句话一说出来答辩老师基本就不会继续追问细节了因为他已经确认你真的理解自己在做什么。6.4 真实性很强的几个扩展点如果你的进度比预期快还有余力下面几个点可以作为扩展功能写进系统每一处都能在答辩时增加厚度库存滚动的月度平均成本计算。入库单价和数量的乘积累加除以总数量自动算出移动加权平均单价出库时按平均单价结转成本让报表里多一列“金额”统计。Excel批量导入物资档案和期初库存。用EasyExcel导入模板管理员可以一次导入几十上百条物资而不是在页面上手动新增这个对卫生所来说非常刚需。物资证照到期提醒。不只是效期供应商的医疗器械注册证、药品经营许可证也有有效期把它们建模为供应商的一个子表同样做日期预警。操作日志的审计界面。管理员可以按操作人、操作时间、模块查询操作记录并且支持导出这就是一个非常完整的审计模块雏形。这些扩展功能选一个做就行不要全上。毕设不是功能越多越好而是主干清晰、支线有一两个亮点就能稳拿好成绩。我见过太多人堆了十几个功能模块结果每个都是半成品答辩时被老师点到细节就卡壳反而不如专注做好核心闭环。最后再分享一个实际体会这套系统真正的难点从来不是代码能不能跑通而是是否理解医疗物资管理中“批次、效期、追溯”这三个关键词的分量。你在设计表结构和写事务逻辑时多问自己一句“这张表删了行不行、这个字段少了会怎样”多这样训练几轮答辩时的底气和熟练度都会上一个层次。准备答辩的那一周把库存流水表里before_quantity和after_quantity的变化对着演示数据讲三遍比你背十页PPT都有用。