“你们的项目是私有化部署还是 SaaS？””同一套代码服务多个客户，分支怎么管理？”——做产品化系统的团队面试必收这两问。它们和”讲讲你的项目”不同：考的不是某个技术点，而是你对”一套代码如何变成多种生意”的理解——这是工程师视角和产品视角的分界线，答好了非常加分。
系列从本篇进入第三章·多客户交付线。前十一章把一个制造执行系统的业务、机制、数据拆了个遍（全景篇开的头），本篇拉高一层：这套底座实际交付出了三种形态——大客户私有化分支、SaaS 云主线、车间工控终端——每一种都对应一类客户和一种交付成本。本篇讲三种形态各自怎么落地、成本压在哪、以及面试里最常被追问的”分支管理”和”形态选择”。
“你在实际项目里用过什么算法？”——这题是业务开发面试的分水岭。背过动态规划的人很多，在真实生产系统里跑过约束求解器的人很少。这个系列的主线机制到此收官，最后一块硬骨头给排产（APS）：用 OptaPlanner 给注塑车间排产——几十张工单、十几台机台、几十副模具，算出一版”哪台机、哪副模、几点到几点”的预排方案，画成甘特图给排产员确认。
本篇讲四件事：排产问题的本质（一个活的 Job-Shop 调度问题）、链式建模怎么把车间现实翻译成求解器语言、三层打分与可配置权重的工程化、以及比算法本身更有面试价值的部分——为什么算出来的方案不敢直接下发，”辅助排产”的人机协同怎么设计。约束求解的教科书到处都有，车间里求解器怎么和人工编辑、在制保护、沙箱回滚共处，才是做过的人才讲得出的东西。
面试聊到物联网数据接入，常见问法是”几千台设备高频上报，怎么扛？”——但制造业 IoT 的真正难点不在量，在乱：每家设备商一套报文格式（协议碎片化），设备本身不讲武德（不发心跳、时钟乱跳、计数器回绕、65535 当真实值上报）。量的问题有一百种通用解法，乱的问题只有一种解法——在接入层之后、业务层之前，放一个又宽又厚的清洗与状态层。
本篇拆这套 MES 的 IoT 接入体系。上一篇任务篇里”设备模次聚合产量”的钩子在这篇收口——不过那笔账（两段式自动报工）已在状态机篇讲过，本篇讲的是它上游的接入侧：多协议怎么收、碎片化报文怎么翻译成标准参数、设备在不讲武德的世界里怎么维持一个可信的状态机，以及一份物联网系统特有的欠账清单。
在制造行业的运维工单排行榜上，”定时任务不执行”常年霸榜——不是因为它难，是因为它平时的正确性完全不可见：任务跑了没动静，不跑也没动静，直到某天运营发现预警没发、报表没出、库存没归档，倒回来查的时候现场早凉了。
教科书答案是 @Scheduled 一行注解。但真实系统用不了它——改一次执行周期要发版、启停一个任务要重启、运营和实施人员完全无法自助、多实例部署还重复跑。这套 MES 的定时任务体系就是为了解决这四件事搭建的：任务存数据库、页面全治理、变更即时生效、集群防重。本篇拆它的两条加载路径（一个真实的生产事故就栽在它们身上）、三层防重设计，以及那张沉淀了三轮排查弯路的排查清单。上一篇总线篇讲的系统事件通道，本篇正好是它最重要的消费者。
面试聊到消息队列，大多数候选人的答案在”削峰、解耦、异步”六个字上就停了。再往深追问就见真章：”一条事件要被十几个服务各自消费，你的事件模型怎么设计？””消费者怎么知道自己该处理哪条消息？””消息丢了怎么办——哪些消息允许丢，想过吗？“最后一问最狠，因为它考的不是组件用法，是对自家业务流量分级的真实理解。
本篇拆这套 MES 的自建事件总线——全景篇机制点清单里”MQ 事件总线”的兑现。它不是引一个 MQ 中间件那么简单：整套总线收在一个所有服务共享的 jar 里（事件模型、队列声明、消费分发、通知落库、多渠道推送），业务服务写一个空配置类继承基类就完成接入。本篇讲它的三个设计核心——位编码事件号、自注册 Handler 容器、广播式预警解除——以及同等重要的部分：一份诚实的可靠性欠账清单。
“库存怎么防超卖？”——这道题的标准答案满地都是：乐观锁、分布式锁、Redis 预扣。但它们回答的是”一次扣减怎么安全”，仓储系统的真问题是另一层：账本本身怎么设计，才能让成千上万笔不同性质的动作（入库、领料、冻结、盘点、调拨、组装）打在同一个账本上，一年到头对得起来。锁是战术，账本是战略。
本篇拆这套 WMS 的库存账本设计。它和已发布的库存双写事故篇（一次事故的显微镜）、上一篇边界篇（倒冲扣料的一生）共同构成库存三部曲：事故篇讲”怎么摔的”，边界篇讲”一笔扣料怎么走”，本篇讲”整个账本为什么散不了架”——三维状态从表、三个收敛原语、多层并发闸、三段式异步簿记，和一条”双写一定会漂、漂了要能自愈”的工程信仰。
“业务流程很复杂的系统，怎么避免 if-else 地狱？”——这是聊到业务项目时最经典的一问，标准答案是”用状态机”，再往深问就是策略模式、状态模式、Spring StateMachine。但教科书只讲到”怎么写”，没讲真实系统里真正的难点：状态机规则要不要允许工厂自己改？改了之后在途的单子怎么办？两个工人同时按按钮，状态会不会飞？
本篇拆这套 MES 的工单状态机——本系列业务味最浓的一篇。前一篇框架篇讲的是”所有页面怎么长一个样”，这一篇讲的是”一个工单从下发到完工，怎么在十几个状态之间安全地走完一生”。它的核心答案可能和很多人的直觉相反：这个系统里最重要的状态机不在 Java 代码里，而在一份可以按工厂配置的流程图 XML 里。
面试聊到业务项目，往上讲是架构（全景篇讲过）、往中间讲是机制（登录会话篇讲过），但真正拉开差距的往往是往下这一层：你和你的团队在业务代码之下沉淀过什么。”讲讲你们的框架封装””写过什么通用组件””反射和注解在实际项目里怎么用的”——这类问题考的不是背概念，而是你有没有真正维护过一套别人每天都在用的基础设施。
这套 MES 的业务代码之下确实压着这样一层：自研框架封装在私服 jar 里，业务仓库里看不到它的源码，但几十个业务模块的每一个列表页、每一个编辑弹窗、每一次字典翻译、每一处分页，都是它在背后撑着。本篇把它拆开：页面引擎怎么用 XML 元数据渲染出整个 EasyUI 界面，模型元数据怎么驱动通用 CRUD，查询管道怎么把反射、分页、字典翻译和 XSS 转义串成一条线——以及这套”半低代码”机制的账本，利和弊我都翻给你看。