开篇先聊一个很多做过餐饮系统或者进过后厨的朋友都有共鸣的场景：自助餐厅每天最头疼的不是菜单怎么定，而是备菜量怎么控。备多了，海鲜、刺身、现烤牛排这类高成本菜品只能倒掉；备少了，客人端着盘子去取餐台发现空盘，体验直接崩。传统做法基本靠厨师长经验拍脑袋，但经验解决不了节假日波动、天气变化、周边商圈活动带来的连锁反应。这套基于SpringBoot的自助餐厅菜品供应优化与分析预测系统，本质上就是把后厨的"经验决策"替换成"数据决策"——通过大数据分析历史销售记录，结合时间、档口、菜品多维特征，预测未来一段时间的菜品销量，再把结果通过可视化大屏直观地推给后厨和运营人员，告诉他们今天每道菜备多少、几点补货、哪些菜品需要重点盯防。项目面向的是餐饮信息化方向的毕业设计，也适合想入门SpringBoot + 大数据可视化全栈开发的读者参考。
1. 后厨备餐的"拍脑袋"困境：这是需求的第一现场
1.1 自助餐运营里最贵的成本，是看不见的浪费
做自助餐厅管理系统，很多人第一反应是"这不就是个订餐/点餐系统换个壳吗"。真去现场蹲过几天就会发现，点餐系统只是记录"客人吃了什么"，真正的业务核心其实是备餐计划和食材损耗控制。
自助餐有个和其他餐饮形态非常不同的特点：菜品供应是预先生产、集中展示、自由取用的。客人走进餐厅之前，后厨已经把所有菜备好摆上取餐台了。这意味着供给侧的决策完全发生在需求发生之前，一旦判断失误，没有任何补救手段——不能像中餐小炒一样客人点完单再下锅。
我拆解过一家中等规模自助餐厅的月度成本结构，食材成本占到营业额的35%到45%，而其中因为备餐过量导致的损耗通常在8%到15%。这个数字意味着，如果一个月营业额50万，仅仅因为"备多了"，就有4万到7万的食材是直接倒进泔水桶的。更隐蔽的问题是备少了，客人取不到想吃的菜品，满意度下降，复购率受损，这个损失账面上算不出来，但真实存在。
所以这个系统最核心的切入点不是"把销售记录可视化"这么简单，而是要把历史销售数据、时间特征、菜品属性综合起来，算出每道菜在下一个经营周期的合理备餐量，并把这个建议以可执行的方式传递出去。
1.2 我拆解出的四类核心需求
在确定技术方案之前，我先把业务场景里真实存在的需求梳理了一遍，分成了四类：
第一类是实时监控需求。餐厅运营过程中，运营经理需要随时知道当前客流情况、各档口取餐热度、哪些菜品即将见底、哪些菜品剩余过多。这对应可视化大屏上的实时数据刷新模块。
第二类是历史分析需求。店长和采购需要知道上周、上个月、去年同期的菜品销售情况，哪个档口是引流主力，哪些菜品属于"叫好不叫座"，这对应多维度数据分析报表模块。
第三类是预测决策需求。根据历史数据预测未来一天或未来一周的销量，生成备菜建议、采购清单和补货计划。这是系统的核心价值，也是和大数据技术结合最紧密的部分。
第四类是预警提醒需求。当实际销量和预测值出现较大偏差，或者某道菜品在当前时段销量异常偏低/偏高时，系统需要主动告警，提醒后厨调整出餐节奏。
需求明确之后，技术选型就顺理成章了。SpringBoot处理后端业务逻辑和接口服务，大数据分析模块处理历史数据的清洗、特征提取和模型预测，可视化大屏承载实时监控和预测结果的呈现。下面逐个环节拆开讲。
2. SpringBoot做主干、大数据做支线：系统架构怎么落地
2.1 为什么选SpringBoot而不是Python后端
很多做数据分析出身的同学看到"销量预测"就习惯性想用Flask或者FastAPI写后端，然后前端再单独起一个框架。实际做下来我强烈建议主干用SpringBoot，原因有三条。
第一，业务模块的复杂度被低估了。这个系统不只是跑一个预测模型而已。菜品管理、档口管理、销售记录录入、用户权限、预警规则配置、大屏接口聚合，这些都是标准的业务CRUD加复杂查询。SpringBoot在这类场景下的开发效率、事务管理、生态成熟度，是Python系轻量框架比不了的。
第二，和前端联调的数据结构约束更清晰。SpringBoot配合MyBatis-Plus做实体映射和分页查询，返回给前端的JSON结构可以通过DTO统一控制。大屏页面需要的聚合数据（比如按小时统计销量、按档口统计占比），可以写专用的SQL查询接口，而不是让前端拿一堆原始数据自己算。
第三，这个方向本身就是主流。搜索"大数据毕业设计"或者"数据分析可视化系统"，绝大多数参考项目都是SpringBoot + Vue的组合。这意味着遇到问题能搜到的排查资料最多，对就业简历的匹配度也更高。我见过太多用Flask做毕设答辩被问"为什么不用SpringBoot"然后卡壳的场面。
2.2 大数据处理链路在本项目里的实际位置
标题里带"大数据"，这是很多人容易跑偏的地方。千万不要一上来就搭Hadoop、Spark集群，自助餐厅这个体量根本用不上，而且会给部署和演示带来巨大麻烦。
我实现的方案是"轻量大数据链路"：
MySQL（历史销售数据） -> Python数据清洗脚本 -> 特征工程 -> 模型训练 -> 预测结果回写MySQL -> SpringBoot读取 -> 大屏展示Python在这里做离线数据分析和模型训练，SpringBoot做业务服务和接口发布，MySQL做统一的数据存储。训练好的模型通过joblib序列化保存，预测脚本每天定时执行一次，把第二天的预测备菜量写入数据库。SpringBoot不需要直接加载模型文件，它只需要查一张supply_recommendation表就行。
这样做的好处是架构清晰，每层只干一件事。Python脚本即使训练时间拉长到几分钟，也完全不影响线上接口的响应速度。将来如果数据量真的大到MySQL扛不住，可以再平滑迁移到ClickHouse或者引入Spark做特征计算，但现阶段完全没必要为了"大数据"三个字自找麻烦。
2.3 数据库和表结构设计
这套系统的表结构不算复杂，但我反复调整过几版，最终稳定的核心表有六张：
| 表名 | 核心字段 | 作用 |
|---|---|---|
| dish | id, name, category_id, cost_price, sale_price, status | 菜品基础信息 |
| category | id, name, sort_order | 档口分类（热菜/冷菜/海鲜/烧烤/甜品） |
| sales_record | id, dish_id, sale_time, quantity, amount, period | 每一笔取餐记录，period区分午/晚市 |
| daily_summary | id, stat_date, dish_id, total_quantity, peak_hour, valley_hour | 按天聚合的菜品销量 |
| supply_recommendation | id, recommend_date, dish_id, predicted_qty, actual_qty, deviation_rate | 预测备菜量和实际销量对比 |
| alert_log | id, alert_type, dish_id, content, status, create_time | 预警记录 |
sales_record是明细表，数据量最大，也是预测模型最核心的数据来源。自助餐厅的取餐记录通常来自POS机或扫码系统，每取一次餐产生一条记录。以一家日均300客流的餐厅为例，每天大约产生5000到8000条记录，一年的数据量在200万条左右，MySQL完全扛得住。
daily_summary是预聚合表，作用是让大屏的按天趋势图、排行图不用实时扫描明细表。当初设计的时候没加这张表，结果大屏每次刷新都要跑几十万行数据的GROUP BY，接口响应直接飙到3秒以上。加了预聚合之后，响应时间降到了200毫秒以内。
3. 菜品销量预测：从特征工程到模型选择
3.1 特征不是"昨天卖了多少"这么简单
销量预测这个环节，真正拉开差距的不是模型选得多高级，而是特征工程做得多细。我第一次跑模型的时候只用了"昨天销量""前天销量"两个特征，效果惨不忍睹，MAPE误差率超过了40%。后来蹲在后厨观察了一周，又翻了大量历史记录，才把特征体系补全。
我最终使用的特征分为三组：
时间特征：星期几、是否周末、月份、是否法定节假日、距离最近节假日的天数。自助餐厅的客流有明显的周末效应和节假日效应。节假日当天的销量通常是平日的1.5到2倍，而且节假日前一天也会有一个小高峰，这些规律必须让模型学到。
历史销量特征：前7天同菜品日均销量、前3天同菜品日均销量、上周同星期几的销量、去年同期同月份的日均销量。注意这里用的是"日均"而不是单日原始值，目的是平滑偶然波动。比如某天因为供应商缺货导致某道菜没上架，当天销量为0，这个数据点如果不处理，直接作为特征会让模型被误导。
外部环境特征：天气状况（晴天/雨天/雪天/温度）、是否周边有大型活动。天气对自助餐的影响非常直接，下雨天客流明显下降，尤其是晚市。温度则影响火锅、烧烤类档口和冷菜、甜品档口的结构变化——天冷了寿司刺身销量跌，天热了火锅档口排队变短。
特征数据怎么收集？天气和温度可以接入第三方天气API按天拉取，存到一张weather_daily表里。节假日信息直接维护一张节假日字典表，因为国内法定节假日每年提前就公布了。
3.2 模型对比：为什么选了回归树而不是时间序列模型
说到预测模型，很多人第一反应是ARIMA或者LSTM这类时间序列模型。我在项目里对比过三类方案，最后的选择可能和你想的不一样。
ARIMA：对单条菜品序列做差分平稳性检验，通过后再定阶预测。问题是自助餐厅的销量序列有很强的星期周期性，ARIMA需要手动做季节性分解，而且每道菜都要单独建模调参。餐厅有80多道菜，每道菜一个模型，维护成本不可接受。
LSTM：理论效果最好，但需要的数据量比较大，单道菜一年的数据根本喂不饱一个像样的循环神经网络。训练时间长，还要装TensorFlow/PyTorch，部署环境瞬间变重。在一个毕设或者中小型项目里属于杀鸡用牛刀。
XGBoost/LightGBM回归树：把问题从"时间序列预测"转化成"回归问题"。每一行样本是"某道菜在某天的销量，以及那天的各种特征"，模型学习特征到销量的映射关系。一个模型可以覆盖所有菜品（把菜品ID也作为特征），训练快，效果稳定，特征重要度还能直接输出，方便解释。
我用LightGBM做最终方案，80多道菜、一年多、约6万条训练样本，训练时间不到10秒，测试集MAPE在18%到25%之间。这个精度对于备餐建议来说已经够用了，它给出的不是精确数字，而是一个合理区间。
实际代码框架大致是这样：
import lightgbm as lgb from sklearn.model_selection import train_test_split from sklearn.metrics import mean_absolute_percentage_error features = ['dish_id', 'weekday', 'is_weekend', 'month', 'is_holiday', 'avg_7d', 'avg_3d', 'same_weekday_last_week', 'weather_code', 'temperature'] X = df[features] y = df['quantity'] X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42) model = lgb.LGBMRegressor( n_estimators=300, learning_rate=0.05, num_leaves=31, max_depth=-1, random_state=42 ) model.fit(X_train, y_train, eval_set=[(X_test, y_test)], callbacks=[lgb.early_stopping(50)]) y_pred = model.predict(X_test) print('MAPE:', mean_absolute_percentage_error(y_test, y_pred))训练完成后用joblib.dump(model, 'dish_model.pkl')保存模型，预测脚本每天加载模型，批量生成第二天的备菜建议。
3.3 从预测到决策：备菜量、补菜点和预警阈值
模型输出的预测值不能直接当成备菜量来用，中间还要加一道决策规则。
比如某道菜预测明天销量是50份，备菜50份看着合理，但一旦客流稍微超出预期，取餐台就会空盘。更稳妥的做法是加上一个安全余量：
备菜量 = 预测销量 × (1 + 安全系数)安全系数根据菜品成本动态调整。成本低的菜品（炒青菜、炒饭），安全系数可以放大到15%到20%，宁可多做一点倒掉，成本也可控；成本高且容易损耗的菜品（三文鱼刺身、烤羊排），安全系数收窄到5%到8%，备少了临时补做也比备多了倒掉划算。
补菜点用另一个公式算：
补菜预警阈值 = 当前剩余量 / 近30分钟平均消耗速度 < 预计补货耗时 + 10分钟这个逻辑落到alert_log表里，每10分钟扫描一次。如果某道菜当前剩余量只够撑15分钟，而补货需要20分钟，就触发预警，提醒对应档口厨师赶紧加量。
我自己实践下来的体会是，预警规则比预测模型更容易被餐厅实际采纳。因为店主对新系统天然不信任，但一个"三文鱼快没了，请马上补货"的提醒是立刻能验证对错的。预测模型跑得再准，如果预警逻辑做不好，整个系统在店长眼里就是一堆看不懂的曲线图。
4. 可视化大屏：把预测结果变成后厨看得懂的指令
4.1 大屏到底要显示什么，不是图表堆砌
做可视化大屏最容易犯的错是"什么图都往上堆"。折线图、饼图、柱状图、雷达图一整屏全是图，看起来很炫，实际盯屏的人根本不知道要看哪里。
我去餐厅实地观察了店长和厨师长的使用习惯，总结出大屏上的信息必须回答三个问题：现在情况怎么样？今天预计怎么样？有没有需要马上处理的事？
围绕这三个问题，最终的大屏布局是这样规划的：
顶部通栏：核心KPI数字。今日客流、当前在店人数、今日累计销售额、今日食材损耗率（估算值），四个数字醒目展示，一眼掌握全局。
中部左侧：各档口实时取餐热度排行。用横向柱状图展示当前时段每个档口的取餐次数，颜色越深代表热度越高。厨师长可以据此判断哪些档口需要增援。
中部中间：客流趋势图和菜品销量预测对比图。折线图展示从开门到当前的实时客流曲线，虚线叠加模型预测的同期参考值，实际值明显高于预测值时触发备货加急。
中部右侧：预警信息滚动列表。这里显示的是alert_log表里status为待处理的高优预警，按紧急程度排序，最多显示10条。点击某条预警可以下钻到对应档口和菜品。
底部：菜品销量TOP10和滞销TOP10。海鲜、烧烤等高价值菜品的排名变化尤其重要，排名骤降可能意味着出品质量问题。
整个大屏的配色我用了深色底加高亮色块，深蓝背景、青色和橙色作为数据主色。深色底的好处是在后厨和餐厅入口的强光环境下对比度更清晰，而且大屏本身是长期亮着的，深色底更省电、不易烧屏。
4.2 ECharts + Vue3实现的核心页面细节
技术栈是Vue3 + ECharts，SpringBoot后端提供JSON接口。大屏页面有四个核心细节值得说一下。
轮询策略：大屏上的实时数据不能只加载一次，但也不能让前端每秒刷一次接口。我采用的方案是：顶部KPI和预警列表每10秒轮询一次，档口热度每30秒轮询一次，趋势图和排行图每5分钟刷新一次。分级轮询既保证了数据的及时性，又不会给数据库造成压力。
下钻交互：点击档口热度排行中的任意一项，弹出该档口的菜品明细面板，显示每道菜的当前剩余量、预测销量、建议补货量和最近一次补货时间。这个交互是厨师长使用频率最高的功能，因为它直接指导现场操作。
空状态设计：自助餐厅有午市和晚市两个经营时段，中间会有两三个小时没有客流。这段时间大屏上显示的不是一堆归零的图表，而是一个"闭餐准备中"的过渡状态，并展示次日备菜预测。这个细节让大屏的使用体验好了很多，不然中午的运营例会对着空屏根本没法讲。
异常值标注：趋势图上的数据点如果触发预警阈值，会用醒目的颜色在高亮圆点附近标出菜品名称和预警原因。图表上的异常标注比滚动列表里的文字告警冲击力强得多。
4.3 适配问题的实战解法
"可视化大屏适配"是热搜词里的高频词，也是很多人在答辩前临时抱佛脚的问题。大屏最常见的使用场景是挂在餐厅墙上的电视或者LED拼接屏上，分辨率可能是1920x1080，可能是3840x2160，也可能是一块奇怪比例的竖屏。前端页面如果写死尺寸，换一块屏幕就全部错位。
我最终采用的方案是基于1920x1080设计稿 + transform scale等比缩放：
function setScale() { const designWidth = 1920 const designHeight = 1080 const scaleX = window.innerWidth / designWidth const scaleY = window.innerHeight / designHeight const scale = Math.min(scaleX, scaleY) document.getElementById('dashboard').style.transform = `scale(${scale})` } window.addEventListener('resize', setScale) setScale()核心思路是：页面始终按照1920x1080的尺寸进行布局，然后通过CSS transform的scale属性把整个页面缩放到当前屏幕的可用区域。Math.min(scaleX, scaleY)保证页面不会被拉伸变形，多出来的边距用背景色和边框装饰填充。
这个方案有两个坑要提前避开：
第一，transform scale不会影响页面在文档流中占用的空间，所以外层容器必须明确设置宽高，并且把transform-origin设为top left，否则缩放的起点不在左上角，页面会往右下偏移。
第二，ECharts实例内部有自己的尺寸管理。单纯缩放CSS不会让图表内部字体和间距跟着变，需要在缩放之后手动调用每个图表的resize()方法，否则图表会保持1920x1080时的内部像素比例，在缩小的屏幕上出现文字挤出边界的情况。我的做法是在setScale函数里遍历一个存有所有chart实例的数组，统一执行chart.resize()。
5. 数据量太小的时候，预测模型根本没法用
5.1 模拟数据生成方案
这是整个项目里最容易被忽视但实际上最先遇到的坑。一家餐厅刚上线系统，手里可能只有一两个月的销售数据，这种数据量训练出来的模型预测结果基本不能看。更常见的情况是——开发阶段你手里连一条真实数据都没有。
所以第一步必须做数据模拟。我写了一个Python脚本，按照"基础销量 + 星期系数 + 节假日系数 + 随机波动"的逻辑生成模拟销售记录。
以一个菜品为例，基础逻辑是：
import random import pandas as pd from datetime import datetime, timedelta def simulate_dish_sales(dish_id, base_qty, start_date, days): records = [] for i in range(days): current = start_date + timedelta(days=i) weekday_coef = {0: 0.8, 1: 0.8, 2: 0.85, 3: 0.9, 4: 1.0, 5: 1.2, 6: 1.15} holiday_coef = 1.8 if current in holiday_list else 1.0 noise = random.uniform(0.85, 1.15) qty = int(base_qty * weekday_coef[current.weekday()] * holiday_coef * noise) records.append({'dish_id': dish_id, 'sale_date': current, 'quantity': qty}) return records模拟数据虽然不能完全等同于真实分布，但能保证模型开发和前端联调不卡壳。餐馆正式上线之后，真实数据会不断积累，模型可以定期用新数据重新训练，逐步逼近真实场景。
另外一个更取巧的方案是冷启动用规则替代模型：新店开业前两个月，预测值直接用"同品类菜品的销售均值 × 菜品热度系数"替代，不跑机器学习模型。等积累了三个月的真实数据之后，再切换到LightGBM。做可视化大屏和预警逻辑完全不受影响，因为后端接口返回的数据结构是一样的。
5.2 特征数据缺失的兜底策略
特征工程依赖天气、节假日等外部数据，但在开发环境和离线测试时，这些数据经常出现缺口。比如调用第三方天气API失败，或者节假日字典表还没维护完整。
我的兜底逻辑是：所有外部特征都设置默认值，天气默认为晴天（天气代码200），节假日默认非节假日（0）。预测脚本跑完以后会生成一个数据质量报告，记录当天有多少比例的特征值来自默认值，如果超过20%，就在日志里告警，提示运营人员检查外部数据源。
这个设计在真实运营中很重要。有一次天气API的调用额度用完了，连续三天所有天气特征都走了默认值，但系统依然稳定运行，预测结果只是精度有所下降。如果没有兜底策略，整个预测链路就会因为一个外部接口的问题瘫掉。
6. 接口轮询优化：别让大数据接口拖垮SpringBoot
6.1 大屏接口的聚合与缓存设计
大屏要的数据在很多情况下不是直接查某一张表就能返回的。比如"当前在店人数"，需要统计入场记录和离场记录的差值；"各档口实时热度"，需要按档口聚合最近30分钟的取餐记录。
如果每个指标都单独写一个查询，一个页面打开要调十几次接口，每次几百毫秒，体验非常糟糕。我的做法是在SpringBoot端做一个大屏聚合接口：
@GetMapping("/api/dashboard/overview") public Result<OverviewVO> getOverview() { OverviewVO vo = new OverviewVO(); vo.setTodayCustomerCount(customerService.countToday()); vo.setCurrentInStore(customerService.countCurrentInStore()); vo.setTodaySalesAmount(salesService.sumTodayAmount()); vo.setTodayLossRate(stockService.estimateTodayLossRate()); vo.setHotCategories(categoryService.hotCategoriesLast30Min()); vo.setTopDishes(salesService.topDishRank(10)); vo.setWarnings(alertService.pendingHighLevelAlerts(10)); return Result.success(vo); }前端大屏顶部区域只调这一个接口，拿到全部渲染所需的聚合数据。聚合接口内部用了SpringBoot自带的@Cacheable做缓存，热点数据缓存15到30秒，保证一次大屏刷新周期内多次请求不会重复查库。
缓存失效策略也要特别注意。我曾经踩过一个坑：喝完缓存之后，预警列表30秒内不变了，结果厨房已经把预警处理掉了，大屏上还挂着"待处理"的红条。最后改成预警接口跳过缓存直查数据库，其他不敏感数据继续走缓存。预警和告警类数据绝对不能走缓存，这类信息必须实时准确。
6.2 MySQL慢查询的排查与优化
预测结果表supply_recommendation的数据量增长很快，每天每道菜一条记录，加上历史数据，几个月就有几万条。大屏端做"近30天预测准确率趋势"查询时，SQL语句如果写得不合适，很容易触发慢查询。
我最开始用的SQL是这样的：
SELECT recommend_date, dish_id, predicted_qty, actual_qty FROM supply_recommendation WHERE recommend_date >= DATE_SUB(CURDATE(), INTERVAL 30 DAY);这条语句本身没有大问题，但每次都要回表查询所有字段，而且大屏五分钟刷新一次，压力不小。优化方案是加联合索引idx_date_dish (recommend_date, dish_id)，并且只查出需要的字段：
SELECT recommend_date, SUM(predicted_qty) AS total_predicted, SUM(actual_qty) AS total_actual FROM supply_recommendation WHERE recommend_date >= DATE_SUB(CURDATE(), INTERVAL 30 DAY) GROUP BY recommend_date;用聚合查询替代逐条记录，前端渲染趋势图时拿到的直接就是按天的汇总值，不需要再做二次处理。加了索引之后，这条接口的响应时间从900毫秒降到了80毫秒左右。
排查慢查询的思路也很直接：MySQL开启慢查询日志，设置阈值为1秒，运行几天后直接看日志文件，排查执行频率高且耗时的语句。我见过很多人一遇到接口慢就怀疑是不是代码写得不对，实际上90%的情况都是SQL没走索引或者查询了不需要的额外字段。
7. 从开发到上线的真实避坑记录
7.1 SpringBoot版本选择与依赖冲突
这是SpringBoot开发里最不值得浪费时间但是几乎每个人都会踩的坑。新建项目的时候，很多人直接选了官网最新的SpringBoot版本，结果和MyBatis-Plus、ECharts前后端联调时莫名其妙报错。
我建议用SpringBoot 2.7.x，不要用3.x。原因很简单：3.x基于Jakarta EE规范，很多老牌的第三方库适配还不到位，网上教程也大多数是2.x时代的写法。刚开始图新鲜用了3.2，结果MyBatis-Plus的启动器兼容性出问题，网上一搜全是"降级到2.7"的解决方案，白白浪费了半天时间。
依赖版本锁定也很关键。在pom.xml里必须显式声明MyBatis-Plus和MySQL Connector的版本号，不要偷懒不写，让Maven自己解析，否则不同环境下可能解析出不同版本，生产环境跑得好好的代码，本机一跑就报ClassNotFoundException。
7.2 ECharts在Vue3里动态渲染不更新
ECharts图表在Vue3中常见的毛病是：数据从后端返回后，图表的setOption调用了但页面不刷新。排查下来基本是同一个原因——图表实例的初始化时机和数据更新时机不同步。
正确的姿势是把图表的初始化放在onMounted钩子里，数据请求完成后用nextTick包裹setOption，并且设置notMerge: true覆盖旧数据：
onMounted(() => { chart = echarts.init(document.getElementById('trendChart')) fetchData().then(res => { nextTick(() => { chart.setOption({ series: [{ data: res.data }] }, true) }) }) })还有一个容易忽略的点：ECharts在容器隐藏或者宽度为0的DOM上初始化会渲染成空白。大屏页面如果用了v-if控制Tab切换，切换到隐藏的Tab时初始化图表，图表宽度会是0。解决方法是保证容器可见后再初始化，或者在nextTick里重新resize()。
7.3 预测模型的落地上线要比想象中多一个"解释层"
最后说一个很多人做完模型就忽略的问题：预测结果算出来了，怎么让厨师长愿意照着做？
如果大屏只显示"明天三文鱼备餐量建议35份"，厨师长很可能嗤之以鼻。但如果大屏同时显示"本周三文鱼日均销量30份，周五通常比周四高15%，明天预报多云转阴，建议备餐量35份，置信区间30到40份"，厨师长就会觉得系统说得有道理。
所以我在预测结果展示层加了一个解释性文案生成模块：根据模型的特征重要度排名，把影响明天销量的前三个因素用自然语言输出。比如"高价值因素：明天是周五（历史周五均比周四高12%）；中等因素：天气预报为晴；负向因素：近3天销量连续下降"。这个模块不需要多么复杂的NLP，就是模板字符串加特征重要度排序，但实际使用效果比干巴巴的数字好得多。
这个细节让我深刻体会到一件事：技术上的准确率不完全等于业务上的采纳率。系统最终是给人用的，把模型输出翻译成人能理解、能信任的指令，和把模型做准一样重要。
整套系统跑下来，我最满意的地方不是准确率有多高、图表有多炫，而是它真正改变了后厨的工作方式——从"凭感觉备菜"变成了"看数据备菜，异常时再凭经验调整"。这套经验也完全可以迁移到其他行业场景，比如食堂、生鲜超市、中央厨房的备货计划。技术选型和架构本身没什么神秘的，SpringBoot负责稳定输出业务接口，Python负责离线分析和模型训练，ECharts负责把结果翻译成直观的视觉语言，每个环节各司其职，系统跑起来就非常省心。
