项目标题里这个“医疗供应链管理系统”我最近半年至少被问过三回。一次是帮某位准备跳槽的兄弟过简历他写的是通用电商项目一次是模拟面试时候选人主动选的题目还有一次是某大厂朋友内推后让我帮忙复盘面试题。共同点很一致大家都觉得手头缺乏一个有行业纵深、能讲清楚架构取舍、还能扛住追问的Java后端项目。电商管理系统已经烂大街了秒杀、下单、库存、优惠券那套面试官闭着眼都能背出答案。医疗供应链系统这个方向恰恰是面试官自己也愿意多聊几句的领域业务复杂度和技术挑战都足够。这篇文章我会把这套系统的完整思路拆开讲从项目选题和微服务划分到领域建模和核心交易链路再到分布式事务、库存扣减、冷链接管这些关键难点的落地实现最后聊简历怎么写、面试怎么讲。内容会偏实战代码和配置可以直接抄作业但更重要的是把每一步背后的“为什么”说清楚。建议手里正在准备Java后端面试、尤其是目标定位在互联网金融科技或大型平台公司的读者认真看完这个项目的可聊深度明显强于普通的管理系统。1. 项目选题与整体设计思路1.1 为什么选医疗供应链这个方向我见过很多候选人的项目列表一眼扫过去全是“某商城系统”“某后台权限管理系统”。这类项目不是不能写而是很难在十分钟内体现你的架构思考。面试官问“你这个订单模块怎么设计状态机”“库存怎么防超卖”你准备的内容基本跟所有人都一样没有记忆点。医疗供应链系统不一样。它天然具备几个面试官非常看重的特点。首先是行业属性鲜明医疗行业对批次追溯、效期管理、冷链监控、合规审计有极高要求这意味着你在设计数据模型时需要处理比电商更细的约束。其次是流程参与者多一个典型的采购入库链路要经过需求方、采购方、供应商、质量验收、仓储、财务多个环节天然的跨服务协同场景非常适合用微服务来拆。第三是领域知识密度足够高你能讲清楚“效期近先出”和普通库存的差异这本身就是一种业务翻译能力的证明。从面试官视角来说医疗供应链这类系统体感上也更接近他们日常工作接触的B端复杂系统而不是教科书式的CRUD。业务复杂度的存在使得微服务拆分、分布式事务、幂等设计、大数据量下的查询优化这些技术点都有了真实的落点而不是为了用而用。1.2 业务边界与微服务模块划分项目规模要控制好。我建议不要一上来就想做一个覆盖全部公立医院和所有药企的“巨无霸”而是先把业务边界收敛到一个具体的场景里。你可以设定为面向某区域医疗集团或某连锁药企的供应链中台向上对接院内采购系统或门店销售系统向下对接多家医药供应商核心品类是药品、耗材、器械。基于这个边界微服务模块可以这样划服务名核心职责典型接口 / 能力auth-service用户认证、组织权限、操作审计登录、菜单权限、数据权限过滤supplier-service供应商准入、资质证照、合同管理供应商档案、证照到期预警purchase-service采购计划、采购订单、审批流订单创建、审批、协同供应商确认inventory-service库存台账、批次管理、效期预警、出入库批次库存查询、效期近先出库、出入库流水quality-service质检任务、批次质检结果、追溯记录质检报告、批次追溯链coldchain-service冷链设备绑定、温度区间设置、超温预警温度上报接收、超温提醒notification-service站内信、短信、企微或邮件通知消息模板、发送记录、失败重试gateway-service统一入口、鉴权、限流、灰度路由动态路由、令牌桶限流这里要说明一个关键设计决策不要把采购、销售、库存合在一个大服务里。虽然从数据关系上看它们确实紧密但业务变化的频率和各自的领域模型差异很大。采购关注审批流和供应商协同库存关注批次和效期合并后不出半年就会因为业务规则膨胀而互相拖累。微服务拆分的核心依据不是数据表而是业务域的独立演化能力。初始版本上线阶段为了降低运维成本前三个服务可以先合并为一个供应商与采购模块。我建议你简历上写清楚拆分演进的过程单体起步按业务域逐步拆出库存、冷链、质量最后形成现在的服务划分。这种设计能力比一开始就铺十几个服务更能打动面试官。1.3 技术选型与技术栈设计技术栈的选择我见过两种极端。一种是只写Spring Boot MySQL Redis完全体现不出分布式系统的复杂性另一种是刻意堆砌Spring Cloud Alibaba全家桶、MySQL分库分表、Kafka、Flink实时计算一问细节就答不上来。我的建议是选择一个“够用且能自圆其说”的组合。具体如下基础框架Spring Boot 2.7 Spring Cloud 2021.0.x Spring Cloud Alibaba注册配置中心Nacos既负责服务注册发现也统一管理多环境配置网关Spring Cloud Gateway负责路由转发和统一鉴权远程调用OpenFeign整合Sentinel做熔断降级超时与重试通过Feign拦截器统一处理分布式事务Seata AT模式解决采购与库存跨服务事务问题可靠消息RabbitMQ用于最终一致性场景和通知类消息缓存与分布式锁Redis库存预占与幂等控制定时任务XXL-Job处理效期预警、冷链温度扫描、订单超时关闭数据库MySQL 8.0核心表按业务域分库不做分表ORMMyBatis-Plus复杂联查用XML自定义SQL你可能会问为什么不直接上Kubernetes Service Mesh那一套。原因很简单如果是真实生产环境容器化部署确实是标配但在面试项目里你能把注册中心、配置中心、网关、熔断、分布式事务这套完整讲透已经非常能打了。Kubernetes名词可能吸引眼球但面试官更关心你对服务发现和流量治理的理解深度。如果时机合适可以在扩展思考里提一句“生产环境会补充容器化部署方案”点到即止。1.4 整体架构与核心链路说明架构分层我习惯用一段话描述清楚浏览器或App端请求先经过网关服务网关完成JWT鉴权和基础限流后按路由规则转发到业务服务。业务服务之间通过OpenFeign调用注册发现走Nacos。每个服务的本地事务通过MySQL保障跨服务的写操作走Seata或可靠消息。Redis承担热点数据缓存和分布式锁RabbitMQ承载采购消息通知、异步库存流水和对账任务。定时任务统一托管在XXL-Job调度中心。业务核心链路是采购入库需求科室或门店提交要货计划采购模块汇总生成采购订单订单经多级审批后发给供应商供应商确认后仓库执行收货质量模块进行批次检验库存模块完成入库并产生批次库存与流水同时冷链模块记录温度轨迹。这条链路走完一次采购入库业务需要同时更新至少四个服务的状态分布式事务和状态一致性就是从这里切入的。整体架构图我在面试时会直接在白板上画出来。建议读者把这张示意图在本地画到滚瓜烂熟能准确说出每个箭头代表的是HTTP调用、异步消息还是数据库读写。画得出来、讲得清楚项目就立住一半了。2. 需求落地与核心难点实现2.1 领域建模与核心数据表设计领域建模这件事很多候选人会忽略但其实最能体现工程素养。医疗供应链的核心实体我认为可以抽象为8个商品档案SKU、供应商、采购订单、订单明细、入库单、批次、库存台账、库存流水。以商品与批次的关系为例这是医疗行业与普通电商最显著的差异。同样一个药品会有不同的生产批号不同批次的效期、质检报告和供应商来源都不同。如果你只在商品表上加一个库存数量整个追溯体系就根本立不起来。正确的做法是让批次成为独立实体库存台账以“SKU 仓库 批次”为粒度记录。也就是说查询某个商品的可售库存时要分组汇总它所有批次的可用数量实际执行出库时则要按照效期近先出策略定位到具体批次。这个设计直接决定了后续库存扣减的复杂度也决定了你能不能讲出“为什么库存服务是独立存在的”这种有深度的话。核心表我给出几个关键字段仅供参考。库存台账表id、sku_id、warehouse_id、batch_id、total_qty、locked_qty、available_qty、version其中version是乐观锁字段用于并发扣减。批次表id、batch_no、sku_id、supplier_id、prod_date、expire_date、质检状态、冷链要求标识。流水表id、biz_type、biz_no、sku_id、batch_id、change_type入库/出库/冻结/解冻、quantity、before_qty、after_qty、operator_id、create_time。设计流水表的目的是所有库存变更都必须可以通过流水完整回溯。这是一条值得在面试中反复强调的设计原则库存台账是结果流水是事实结果可以被修改事实只能追加。采购订单状态机建议如下表设计状态含义可流转至DRAFT草稿PENDING_APPROVALPENDING_APPROVAL待审批APPROVED / REJECTEDAPPROVED审批通过CONFIRMED_BY_SUPPLIERCONFIRMED_BY_SUPPLIER供应商已确认PARTIALLY_RECEIVED / RECEIVEDPARTIALLY_RECEIVED部分入库RECEIVEDRECEIVED已入库完成FINISHEDFINISHED已完成—CANCELED已取消—写状态机时的注意事项状态字段不要直接暴露为前端随意修改的数字而是定义一个枚举类统一管理流转规则状态变更记录在单独的状态变更日志表里方便事后审计。多数候选人的项目没有状态变更日志你能加这一层面试官对你的工程严谨度评价会明显高一个档次。2.2 库存扣减、批次锁定与效期策略库存扣减是这类项目里被问得最频繁的硬核点之一。电商里常见的做法是扣总数但医疗供应链里必须精细化到批次。这里涉及到FEFO效期近先出策略即有效期近的批次优先出库这样可以最大可能避免药品过期损耗。精确到批次的库存扣减在并发场景下会引入复杂性问题。常见的场景是02号批次还有效期两年03号批次还有一个季度到期系统会优先分配03号批次。但此时可能有多个订单同时锁定03号批次如何防止超卖我的方案是Redis预占加数据库最终校验的双层控制。Redis里用Hash保存每个SKU的可用库存池key设计为sku:stock:{skuId}字段分为total、locked、available。扣减时执行一段Lua脚本首先校验available是否充足充足则扣减available并增加locked不足则返回失败。这个操作原子完成避免了常规先查后扣导致的竞态。Lua脚本示例大概如下local available_key KEYS[1] .. :available local locked_key KEYS[1] .. :locked local qty tonumber(ARGV[1]) local available tonumber(redis.call(GET, available_key) or 0) if available qty then return -1 end redis.call(DECRBY, available_key, qty) redis.call(INCRBY, locked_key, qty) return 1数据库层面出库单提交时要再次执行条件更新防止Redis数据与数据库不一致UPDATE stock SET locked_qty locked_qty #{qty}, available_qty available_qty - #{qty}, version version 1 WHERE sku_id #{skuId} AND batch_id #{batchId} AND available_qty gt; #{qty} AND version #{version}受影响行数为0时说明并发冲突系统就需要回滚或重新分配批次。这里还要处理好预占失败时对可用批次进行重试的策略以及订单超时后对locked数量的释放。2.3 采购入库到库存可售的分布式事务链路这条链路如果用单体系统实现一个本地事务就能搞定。但拆分服务后订单状态更新、入库单生成、库存增加、批次创建、质检结果回写涉及多个服务本地事务已经无能为力。我的选择是对强一致场景采用Seata AT模式对最终一致场景采用可靠消息。先看强一致场景采购确认收货这个操作必须同时完成采购订单部分入库状态更新与库存台账增加。如果库存增加成功而订单状态没更新库存对账就会出现缺口。这里通过GlobalTransactional标注入口方法使得多个本地事务合并为一个全局事务。Seata AT模式的原理是第一阶段本地提交并生成undo_log第二阶段根据全局事务结果异步删除undo_log或反向补偿回滚。它最大的优势是侵入性小业务代码几乎无感劣势是AT模式对运行效率和锁粒度有一定代价不适合极高并发场景。在医疗供应链这类操作频次不高的内部系统里AT模式是相当合适的选择。对于最终一致场景比如入库完成后要通知供应商结算、通知质量部门抽查这类通知失败不能影响主流程就采用RabbitMQ可靠消息。发送端本地事务中写入消息记录表并发布消息消费端处理成功后通过消息幂等键去重。这套方案的优点是不占用数据库长事务抗故障能力强。面试时如果被问“什么时候用Seata、什么时候用MQ”回答思路其实很简单主流程数据必须强一致时用全局事务旁路通知和可容忍短暂延迟的环节用最终一致。2.4 效期预警、冷链监控与定时任务设计医疗供应链里效期管理不只是数据层面的到期判断还包括分阶段预警。比如效期剩余6个月时预警采购停止新购剩余3个月时强制锁定不可向患者出具到期后自动转为报废。这个规则不同医疗机构的定义会有差异所以我把预警阈值做成了配置化。具体实现上可以用XXL-Job每天凌晨执行一次批次扫描按配置的日期阈值批量更新批次的预警状态并生成预警工单发送给相应业务人员。为了防止任务执行时间过长影响主库扫描采用分段拉取每次只取2000条批次用游标方式推进处理避免一次性加载全表。冷链监控这个点非常有行业特色。冷链药品要求在特定温度区间内存放温度记录由仓库冷库传感器定时上报。接收服务将上报数据写入Kafka或RabbitMQ消费端进行窗口统计如果连续15分钟超出阈值就触发告警并生成运维工单同时提供历史温控曲线查询用于飞行检查或质量追溯。这一块虽然属于边缘逻辑但在面试里能有效展示你对数据处理管道的思考。我在实际项目中遇到过一个问题温度上报消息由于网络闪断出现乱序导致窗口统计误判超温。解决思路是对每条上报数据附加设备端时间戳消费端做事件时间的乱序处理如果希望逻辑更严谨就接入Flink做事件时间窗口但为了控制项目复杂度可以用Redis记录每个设备的最近上报时间戳来过滤过期消息。这个取舍讲给面试官听非常加分。3. 关键代码实现与中间件实战3.1 库存冻结、出库扣减与异常回滚的完整实现库存服务的核心接口是预占、确认、释放。预占在Redis里完成确认时更新数据库并删除Redis缓存释放则反向调整。这个流程的关键在于异常分支要识别清楚预占成功但数据库确认失败必须执行补偿逻辑释放预占。我写过一个伪代码风格的流程方便你理解整体逻辑Transactional public DeliveryResult deductStock(DeductCommand cmd) { // 1. 查出可用批次按FEFO排序 ListBatchStock batches getAvailableBatches(cmd.getSkuId(), cmd.getQty()); if (CollectionUtils.isEmpty(batches)) { throw new BizException(批次库存不足); } // 2. 预占Redis Lua扣减 for (BatchStock batch : batches) { boolean reserved stockReserveService.reserve(batch.getSkuId(), batch.getBatchId(), batch.getAllocatedQty()); if (!reserved) { // 释放前面批次回到统一失败 releasePreviousBatch(batches, index); throw new BizException(库存预占失败); } } // 3. 数据库条件更新存在并发则失败回滚 int affected stockMapper.deductByCondition(batch.getSkuId(), batch.getBatchId(), allocatedQty, batch.getVersion()); if (affected 0) { releasePreviousBatch(batches, index); throw new OptimisticLockException(); } // 4. 写库存流水 stockFlowMapper.insert(buildFlows(batches, cmd)); return DeliveryResult.success(buildOutDetails(batches)); }这里有一个非常重要的细节预占和数据库确认只是“逻辑”上的先后因为Redis的Key过期、网络抖动、数据库超时等都会导致两边的数据不一致所以必须要有定时任务做差异对账把Redis与数据库的差异账单捞出来修正。对账任务我会在每个整点和半点运行一次扫描产生差异的生产流水号。虽然数据库和缓存最终能自愈但面试中能主动讲出这个对账细节的候选人确实不多。3.2 基于Seata的采购与入库事务落地引入Seata之后不是把所有方法都加GlobalTransactional就万事大吉。我在实操中总结了几条必须注意的限制。Seata AT模式对数据库隔离级别是要求支持的默认分支事务是读已提交。业务上要注意全局事务执行时间不能太长长时间占用锁会造成大量后续请求等待。因此不要在全局事务里做远程接口调用外部系统、发送短信、调用三方接口等耗时操作。正确做法是把耗时的旁路动作挪到事务提交后的消息队列处理。还有一点Seata AT模式要求所有参与事务的表必须有undo_log表。建议在库存服务、采购服务里分别为参与全局事务的每张业务表建立同名独立的undo_log并设置定期清理任务否则事务日志会像滚雪球一样涨最后影响数据库性能。我当时因为忘记清理三个月后undo_log表比业务表还大这个坑大家绕开。源码层面核心入口可以这样标注GlobalTransactional(rollbackFor Exception.class) public ReceiveResult executeReceive(ReceiveCommand cmd) { // 1. 创建入库单并改为部分收货状态 receiveService.createAndUpdate(cmd.getReceiveBill()); // 2. 更新采购订单收货状态 purchaseClient.updateReceiveStatus(cmd.getOrderId(), cmd.getReceivedQty()); // 3. 库存服务异步追加可用库存 inventoryClient.addInventory(cmd.getSkuId(), cmd.getBatchId(), cmd.getQty()); // 4. 质量服务登记批次质检状态 qualityClient.initQualityRecord(cmd.getBatchId()); return ReceiveResult.success(cmd.getReceiveId()); }这个入口里一旦任何一步失败前面所有本地提交全部回滚业务不会出现“订单已收货但库存没加”的中间态。3.3 接口幂等与消息消费防重设计医疗供应链里的很多上游系统会做重试比如采购系统收到银行回调、审批系统回调、对接院内系统时网络不确定导致上游重发。接口幂等如果不能做好最直接的后果就是重复生成采购订单、重复扣库存、重复发通知。我给所有写接口设计了一个强制约定凡是可以由客户端生成的唯一请求标识必须在请求头里带回。服务端用Redis的setIfAbsent做幂等控制String idempotentKey idem: request.getOperationType() : request.getRequestNo(); Boolean first redisTemplate.opsForValue().setIfAbsent(idempotentKey, 1, Duration.ofMinutes(30)); if (Boolean.FALSE.equals(first)) { return resultWrapper.alreadyProcessed(); }这个方案在大多数场景下都够用但要注意如果Redis发生持久化延迟并主从切换极端情况下可能丢失幂等标记。所以数据库里还要对唯一业务键做约束。比如采购订单表对order_no加唯一索引消息消费表对message_id加唯一索引。这两道防线加在一起即使Redis短时间失效数据库也能拦截重复数据。对于MQ消费我采用“事前去重表”和“消息表驱动业务”的做法。消费者收到消息后先查幂等表是否存在相同消息ID不存在则插入幂等记录并执行本地业务若执行失败则回滚删除幂等记录以便下次重试重新处理。这套方案虽然多了一次数据库查询但换来了消息不丢不重的可靠边界。3.4 缓存一致性策略与热点处理医疗供应链虽然不像电商秒杀那样有极端热点但商品档案、科室科室库存查询这类读多写少的场景很容易成为系统瓶颈。我的缓存策略是两级每天变更极少的主数据使用Caffeine本地缓存过期时间5分钟库存和批次数据使用Redis缓存采用先更新数据库再删除缓存的方式。这个方案有一个已知的并发问题查询请求在缓存删除前刚好读到旧值然后把旧值回填。解决手段是延迟双删即数据库更新完成后删除一次缓存等待500毫秒再删除一次把和并发读之间产生的脏回填清除掉。500毫秒的时间可以根据业务容忍度调整一般内部系统取这个值就可以。如果面试官追问更高级的方案可以提一下基于Canal订阅数据库binlog变更由消费端异步刷新缓存或删除缓存。这样业务服务不用自己关心缓存删除缓存一致性由事件驱动统一保证。当然这个方案会增加一条Kafka消费链路复杂度更高属于锦上添花的加分项适合聊完基础方案后作为延伸展开。4. 简历呈现与面试实战问答4.1 如何把项目亮点浓缩到简历上简历篇幅有限项目介绍部分不要写成流水账。我建议用“一句话定位 三个亮点 一个量化结果”的结构。一句话定位示例基于Spring Cloud Alibaba微服务架构设计并实现面向区域医疗集团的药品供应链管理系统覆盖采购、库存、批次效期、冷链监控等核心业务链路。三个亮点可以这样选主导库存模块设计实现基于Redis预占与数据库条件更新的库存扣减方案支持FEFO效期近先出策略精确控制批次级超卖。引入Seata分布式事务解决采购收货与库存变更的跨服务一致性问题采用可靠消息保证通知类业务最终一致整体数据不一致率在压测中降低为零。设计统一的接口幂等与消息防重机制通过Redis幂等标记加数据库唯一约束双重保障避免了上游系统重复回调导致的重复订单问题。量化结果可以写模拟500并发采购入库场景下单事务成功率99.6%库存扣减接口P99耗时为138ms压测期间未出现超卖和重复单。你来我往的追问场景中量化数字往往是引发面试官兴趣的引子。4.2 面试必问的几个问题与回答框架微服务拆分依据是什么。这是最容易被问的。回答时可以强调基于业务域与变化频率的差异来拆然后举采购订单与库存的例子一个关注审批流和供应商协同一个关注批次与效期未来可能会发生产品差异化规则变化放一起会导致改动冲突。再用数据域归属作为兜底比如库存相关表只能由库存服务访问其他服务必须通过接口调用。Seata AT模式与TCC模式怎么选。回答方向AT模式适合中等并发、以数据库操作为主、对侵入性敏感的内部系统开发效率高补偿逻辑少TCC适合高并发、资金类核心场景因为Try/Confirm/Cancel各阶段逻辑可控不需要全局锁。医疗供应链系统内部操作的并发量并不高选AT模式更务实。如果面试官追问为什么不用两阶段提交可以回答2PC同步阻塞时间长资源释放慢不适合高并发接口场景。缓存数据如何保证正确。回答方向先更新数据库再删除缓存延迟双删加上对账任务兜底升级方案是基于binlog监听刷新缓存。这个回答建议控制在1分钟以内讲完重点放在兜底方案不要在大方向上纠缠。库存超卖如何杜绝。回答方向Redis Lua脚本预占 数据库乐观锁条件更新 最终对账三层闭环。这是最核心的技术亮点必须把它讲得滚瓜烂熟。全局链路如何排查问题。回答方向全链路TraceId透传和日志聚合在网关入口生成TraceId通过Feign拦截器传递到下一个服务日志统一采集后按TraceId聚合检索再补充一句压测时通过这个机制快速定位过一次冷链消息堆积问题。这样既有方案、又有实战证据。4.3 项目讲述的节奏与引导技巧面试讲项目最怕平铺直叙没有起伏。我的建议是采用“业务链路 → 技术难点 → 方案设计 → 方案取舍 → 数据佐证”的叙述节奏。先用1分钟讲清整条业务链路从要货计划开始到采购审批再到供应商确认、收货入库、批次质检、库存可售、冷链预警。让面试官对项目全貌有基本认知。然后引出第一个难点跨服务数据一致性。说明把采购和库存拆成两个服务之后一个简单的“采购收货后库存增加”就变成了全局事务问题。紧接着给出方案Seata AT模式解决强一致可靠消息解决最终一致。指出为什么这么选而不做别的方案。最后用压测数据收尾。讲述过程中要主动埋“钩子”。例如提到FEFO策略时可以自然停顿一下说“这里关于批次分配其实有个很麻烦的并发问题”然后把预占和数据库条件更新的实现讲出来。主动引导面试官追问你自己最熟悉的部分永远比被动应对舒服得多。4.4 被追问时容易暴露的弱点和应对方法候选人最常见的问题是只背方案、讲不出取舍。举个例子你说用了caffeine缓存面试官如果问“为什么不用pure Redis做缓存”你如果只回答“大家都这么用”就露馅了。正确的应对是讲清楚Caffeine的进程内缓存访问延迟是微秒级适合高命中的配置类数据Redis访问是网络I/O在局域网内部也有毫秒级延迟对于热的主数据而言并不划算。如果能再把淘汰策略和缓存雪崩处理讲出来这个问题就变成了加分项。另一个容易暴露的弱点是数据模型设计不合理。很多人会把采购订单的所有状态、数量、摘要全部冗余在主表里导致字段爆炸。我建议的是主表存基础信息明细表和状态日志各司其职通过订单号聚合。这样既便于审计也便于未来扩展新状态而不需要改表结构。能在面试中主动表达“冗余字段要克制”这个理念通常会让面试官觉得你有真实设计经验。还有一个常被追问的点为什么有一个冷链接管模块它和普通告警系统有什么区别。回答要强调医疗冷链具有合规性质温度记录需要留存并且不可篡改所以不仅要对实时温度做监控还要对历史温度轨迹做不可变归档一旦出现质量问题需要能根据批次号和设备号回放整个运输或储存过程的温度曲线定位到哪个环节超标。这就把单纯的监控系统拔高到了质量追溯和合规层面故事完整度一下就有了。4.5 项目演示与代码讲解过程中的加分习惯如果有现场演示或代码走读的机会我强烈建议准备一个“最小可用链路”的demo脚本。比如从采购下单开始到审批通过到确认收货再到库存查询全程走通耗时控制在5分钟以内。演示时不要直接点按钮而是先讲“我现在做的是预占操作注意Redis里面的available和locked值变化”这是最能直观展示技术深度的时刻。代码走读优先展示三块库存扣减服务的Lua脚本、Seata全局事务入口类、RabbitMQ消费者里的幂等判断。这三个文件都能在两分钟内讲明白且信息密度极高。相反如果面试官随手点开某个Mapper XML里面有几百行复杂SQL你要能立刻解释清楚这条SQL的索引计划以及为什么这么写。准备不充分时看到复杂SQL很容易卡壳所以在面试前把所有耗时超过300ms的SQL都跑一遍EXPLAIN做到心中有数算是一种基本功。真正到了项目答辩阶段你还可以准备一个约五页的PPT材料包含架构图、核心链路时序图、库存扣减流程图、问题复盘记录和数据压测报告。即使面试官没有明确提出要看这些材料都是你项目完整体验的证明主动展示得越自然越好。5. 实战经验与复盘总结项目做完之后建议先别急着投简历做几轮“对抗性自问自查”对每个技术方案尝试以面试官身份挑刺然后尝试回答能否自圆其说。我在某次内推面试前就干过这件事结果真被问到“你为什么不用本地消息表而用Seata”因为我提前准备过回答得非常流畅。另外一个体会是医疗供应链这类B端系统比纯互联网C端系统在面试中的优势在于业务逻辑复杂度和合规要求天然带来了更多的技术挑战。但前提是你真的亲手写过关键代码而不是只读过别人的项目文档。别以为把某开源项目的代码贴到简历里就能过关面试官问“这段库存预占的Lua脚本哪里最容易出问题”你答不上来简历就废了。最后分享一个我在实现过程中的经验把所有业务规则的来源都记录成文档不一定是几十页的需求规格而是每条规则旁边注明出处和决策理由。比如效期预警阈值6个月、3个月、30天这些数字不是拍脑袋定的依据是某次医疗质控内部的调研结论和药监部门飞检反馈。你在面试中随口说出这种业务依据说服力远大于“系统就是这么设计的”。这套做法在后续项目答辩和绩效复盘里也反复起到了作用认真维护业务规则文档的习惯收益比想象中大得多。