门店经营数据大屏 · 实时经营看板产品系统

1、立项原因：连锁门店的经营数据分散在 POS、小程序、电商中台三处，店长看 POS、运营看中台、老板看微信报表，同一家店三个营业额，开会先花半小时对数，等数对完当天的动作已经错过了。
2、行业场景：42 家门店的零售连锁，早高峰与晚高峰各有一波集中成交，门店和总部都需要"当下这一刻"的数字而不是昨天的日报。业务背景是大屏长期挂在门店和总部的电视上，要求长时间运行不卡顿、不涨内存、数字口径与财务一致。

1、功能模块：核心指标区、营业额与订单量趋势、渠道销售占比、品类销售额 Top 榜、实时成交滚动、门店排行、指标口径配置。
2、主要功能描述：顶部五个核心指标（营业额、订单量、客流、毛利率、库存周转）带同比箭头；左侧近 14 天营业额与订单量双折线带面积渐变；中间渠道销售占比环形图区分小程序、POS、电商三个渠道；下方品类销售额 Top 榜与实时成交滚动列表，每笔成交进来即插到顶部。数字统一走同一套指标口径（只算已支付、剔除退款、按下单门店归属），避免总部与门店对不上账。前端只做渲染不做计算，聚合与口径全部在服务端完成，因此大屏长时间挂着内存稳定。

1、我负责的部分：独立完成指标口径定义、数据表与聚合接口设计、WebSocket 增量推送、大屏前端渲染与电视端适配、部署与长时间运行调优。
2、技术栈与亮点：后端 Python + FastAPI，MySQL 存业务数据，Redis 缓存聚合结果，WebSocket 做增量推送而不是前端轮询；前端纯原生 + SVG/ECharts，不用重框架，冷启动 200ms 内出图。亮点是"增量而不是全量"——只推变化的那几条成交和新聚合值，3 秒刷新一次，挂一周内存曲线是平的。难点在迟到数据的处理：POS 断网补传时可能晚到几小时，做法是给每条成交带业务时间戳，聚合按业务时间归集，迟到的数据回补到对应时段并推送一次修正增量。