如果把后厨屏理解成“后台列表换个皮肤”，你大概率会低估它的复杂度。真正的后厨屏不是看一张订单表，而是要同时知道哪单、哪一行、在哪个阶段、带了哪些配料和属性，还要能实时响铃。
这篇文章主要参考了以下企业版源码入口：
enterprise/pos_enterprise/models/pos_prep_display.pyenterprise/pos_enterprise/models/pos_prep_order.py
一、这篇功能真正解决什么问题
pos_enterprise 里的 preparation display 解决的是后厨工作台的数据组织问题。厨房不是财务报表，不接受“点开订单再看明细”的交互；它需要屏幕一打开就拿到足够完整的数据，少跳转、少等待、少猜测。
二、核心链路怎么走
1. display 自己声明要加载哪些模型
_load_preparation_data_models() 返回的不是一个模型，而是一串相关模型：pos.prep.order、pos.prep.line、pos.prep.state、pos.order、product.product、product.attribute、product.template.attribute.value 等。官方很明确：后厨屏需要的是一个局部业务图谱，而不是单点查询。
2. load_preparation_data() 负责把首屏数据一次打包
这个方法会先读当前 pos.prep.display 本身，再遍历每个关联模型，调用各自的 _load_pos_preparation_data(...)。如果某个模型因为权限报 AccessError，它会优雅地退成空列表，而不是整屏崩掉。这一点对餐饮现场非常重要。
3. 后续更新靠 bus 通知，而不是整屏重载
当 pos.prep.order.process_order() 检测到订单有 preparation change，会找到命中的 display，然后调用 _send_load_orders_message()。这说明首屏取数和增量刷新是两套协同机制：前者解决“打开能看”，后者解决“变化及时到”。
三、新手最容易踩的坑
- 以为后厨屏只要查
pos.order就够了，结果配料、属性、自定义值全丢。 - 以为实时刷新就是前端轮询。实际上官方更倾向 bus 通知驱动，减少整屏反复重取。
- 以为权限异常会直接暴露成错误页。源码在加载阶段已经做了容错处理。
四、实战落地时最该盯的点
- 新增自定义口味、配料或打印字段时，先想清楚它属于哪一层模型，后厨屏有没有跟着装载。
- 如果门店抱怨“偶尔不刷新”，先查
process_order()有没有判断出 change，再查 display 通知是否发出。 - 别把后厨屏当后台报表优化；它更像一个事件驱动的作业终端，优化思路完全不同。
五、结论
Preparation display 真正的难点，是把订单、行、阶段、产品属性和实时通知揉成一套可工作的前端数据图。明白这一点，很多“为什么不是直接查订单表”的疑问自然就消失了。
DISCUSSION
评论区