面试聊到消息队列，大多数候选人的答案在”削峰、解耦、异步”六个字上就停了。再往深追问就见真章：”一条事件要被十几个服务各自消费，你的事件模型怎么设计？””消费者怎么知道自己该处理哪条消息？””消息丢了怎么办——哪些消息允许丢，想过吗？“最后一问最狠，因为它考的不是组件用法，是对自家业务流量分级的真实理解。
本篇拆这套 MES 的自建事件总线——全景篇机制点清单里”MQ 事件总线”的兑现。它不是引一个 MQ 中间件那么简单：整套总线收在一个所有服务共享的 jar 里（事件模型、队列声明、消费分发、通知落库、多渠道推送），业务服务写一个空配置类继承基类就完成接入。本篇讲它的三个设计核心——位编码事件号、自注册 Handler 容器、广播式预警解除——以及同等重要的部分：一份诚实的可靠性欠账清单。
“库存怎么防超卖？”——这道题的标准答案满地都是：乐观锁、分布式锁、Redis 预扣。但它们回答的是”一次扣减怎么安全”，仓储系统的真问题是另一层：账本本身怎么设计，才能让成千上万笔不同性质的动作（入库、领料、冻结、盘点、调拨、组装）打在同一个账本上，一年到头对得起来。锁是战术，账本是战略。
本篇拆这套 WMS 的库存账本设计。它和已发布的库存双写事故篇（一次事故的显微镜）、上一篇边界篇（倒冲扣料的一生）共同构成库存三部曲：事故篇讲”怎么摔的”，边界篇讲”一笔扣料怎么走”，本篇讲”整个账本为什么散不了架”——三维状态从表、三个收敛原语、多层并发闸、三段式异步簿记，和一条”双写一定会漂、漂了要能自愈”的工程信仰。
“业务流程很复杂的系统，怎么避免 if-else 地狱？”——这是聊到业务项目时最经典的一问，标准答案是”用状态机”，再往深问就是策略模式、状态模式、Spring StateMachine。但教科书只讲到”怎么写”，没讲真实系统里真正的难点：状态机规则要不要允许工厂自己改？改了之后在途的单子怎么办？两个工人同时按按钮，状态会不会飞？
本篇拆这套 MES 的工单状态机——本系列业务味最浓的一篇。前一篇框架篇讲的是”所有页面怎么长一个样”，这一篇讲的是”一个工单从下发到完工，怎么在十几个状态之间安全地走完一生”。它的核心答案可能和很多人的直觉相反：这个系统里最重要的状态机不在 Java 代码里，而在一份可以按工厂配置的流程图 XML 里。
面试聊到业务项目，往上讲是架构（全景篇讲过）、往中间讲是机制（登录会话篇讲过），但真正拉开差距的往往是往下这一层：你和你的团队在业务代码之下沉淀过什么。”讲讲你们的框架封装””写过什么通用组件””反射和注解在实际项目里怎么用的”——这类问题考的不是背概念，而是你有没有真正维护过一套别人每天都在用的基础设施。
这套 MES 的业务代码之下确实压着这样一层：自研框架封装在私服 jar 里，业务仓库里看不到它的源码，但几十个业务模块的每一个列表页、每一个编辑弹窗、每一次字典翻译、每一处分页，都是它在背后撑着。本篇把它拆开：页面引擎怎么用 XML 元数据渲染出整个 EasyUI 界面，模型元数据怎么驱动通用 CRUD，查询管道怎么把反射、分页、字典翻译和 XSS 转义串成一条线——以及这套”半低代码”机制的账本，利和弊我都翻给你看。
面试官问”介绍一下你最有代表性的项目”，很多人的第一反应是把技术栈从前往后背一遍：”Spring Boot、Spring Cloud、MyBatis、Redis、RabbitMQ……”背完就冷场了。技术栈是名词，不是项目；面试官想听的是这套系统在解决什么问题、被拆成了什么形状、难题是怎么解的——而这恰恰是最难临时抱佛脚的部分。
所以我准备写一个”MES+WMS 面试备战”系列，把我手里这套跑了多年的制造执行系统（MES）加仓储管理系统（WMS）当成标本，由上至下拆架构、由下至上拆机制，翻来覆去把它讲透：每个模块为什么存在、每个技术选型解决了什么痛点、每个机制点背后埋着哪些面试考点。系列里大部分篇目会配真实的踩坑复盘，本文是第一篇——全景篇，目标是让读者不接触任何一行代码，也能在十分钟内回答”这套系统在做什么、长什么样、一个请求怎么走完全程”。
即使你做的不是制造业系统也没关系：多服务拆分、多租户隔离、状态机、异步事件、跨库数据一致性，这些问题的形状在任何行业的后端系统里都是一样的。本文做了脱敏处理，公司、客户、内网地址均不涉及。
接手 MES 系统的第一周就被一个问题教育了：这套系统是模型驱动的——页面、接口、校验规则全部由各模块的模型 XML 声明，启动时统一注册进内存容器。改一行 XML 想看效果？重启整个后端，喝完一杯水回来还没好。而所谓”改模型”恰恰是日常开发里最高频的动作。
于是写了一个两三百行的 Java Agent：改完 XML、mvn compile 落盘，运行中的 JVM 两秒内自动重载新模型，不用重启。这个项目体量很小，但把 Java Agent、Attach API、ClassLoader、NIO 文件监听这几块面试高频知识全部串了一遍。这篇文章拆解它的机制与原理，每部分附上对应的面试考点，文末还附一版按真实追问链演练的模拟面试——这个小项目完全可以当 JVM 方向的自我介绍弹药库。
制造系统里有个经典场景：工人手持终端扫一个箱码，点「生产入库」。那天接口卡了二十多秒，工人以为没点上，又点了一次——两次请求都成功返回，库里多了一模一样的两套库存：库存明细、状态表、入库记录、操作流水，四张表整整齐齐各两行。
代码里明明有查重校验（”当前条码已入库，不可重复入库”），为什么两次都没拦住？这篇文章完整复盘根因链：类级注解把整个入库方法包成一个大事务 → 事务内 MVCC 快照读对并发未提交的插入天然失明 → check-then-act 查重形同虚设 → 生产库唯一索引恰好是普通索引，最后一道兜底也不存在。以及修复方案里一个容易被一笔带过的细节：多条码批量提交时，为什么要按条码排序后依次获取锁才不会死锁。最后附上面试视角的问答拆解——这个问题几乎覆盖了 MVCC、锁、事务、隔离级别的全部高频考点。