麻辣烫次日订货与泡发排程工具——订货单带泡发闹钟，几点开泡算给你看

你是资深前端工程师。请为我（麻辣烫店负责订货的人）做一个单文件
HTML 工具，无任何外部依赖、无构建步骤，保存为 .html 双击就能用，
手机浏览器也能用。所有计算在本地完成，不请求任何网络。

工具名：次日订货与泡发排程

一、数据维护区（菜品库）
- 每个菜品一条记录：名称、类别（叶菜 / 丸冻 / 干货泡发 / 调料 /
  肉类）、单位（斤 / 袋 / kg）、日均销量、当前库存、安全库存天数
- 干货泡发类额外两个字段：泡发时长（小时）、需要用到的最早时间
  （默认次日开档后一小时，可改）
- 支持增删改，数据存 localStorage，下次打开还在

二、订货单生成（按钮触发）
- 计算：建议订货量 = max(0, 日均销量 × 安全天数 − 当前库存)，
  向上取整到「常用采购单位」（如按袋、按件）
- 天气 / 客流修正：一个手动系数输入框（默认 1.0，雨天调低、
  周末调高），系数只作用于建议订货量，不改菜品库里的日均销量
- 输出表格按「断货风险」降序：断货风险 = 当前库存 ÷ 日均销量
  （天数越少越靠前），风险相同的按建议订货量降序
- 生成一段纯文本订货单（品名、数量、单位），带「复制」按钮，
  粘到微信就能发给供货

三、泡发排程表（和订货单同屏，联动生成）
- 只列干货泡发类
- 每样计算：开泡时间 = 需要用到的最早时间 − 泡发时长
- 按开泡时间分两栏：今晚（收档前）该泡的、明早该泡的，
  各按时间先后排
- 硬校验：开泡时间 + 泡发时长 > 需要用到的最早时间的（泡发时长
  超过隔夜时长的除外，这类自动归「今晚」），整行标红并给出
  提示「泡发来不及，要么今晚早泡、要么换短泡发的替代」

四、验收标准（做完自测这三条）
1. 建一个菜品「木耳」，泡发时长 2 小时、要用时间次日 10:00，
   排程表应出现在「今晚」或「明早」中开泡时间 = 08:00 的
   位置（按本机当前时间落在哪边就归哪边）
2. 建一个「腐竹」，泡发时长 6 小时、要用时间次日 10:00，
   若当前已过 20:00 则标红并提示来不及
3. 清空 localStorage 后刷新，页面应显示空态引导而不是报错

界面要求：单屏为主，两个区块左右（手机上下）排布；配色朴素，
字号偏大——使用场景是后厨，戴着手套、屏幕有水汽。

限制：
- 不引入任何 CDN、字体、图标库——完全离线可用
- 不做用户系统、不做云端同步——localStorage 是唯一的存储
- 不放任何「行业日均销量」的预填数据——所有数字由我录入
- 代码里不写死任何具体菜品名，全部来自我维护的菜品库

为什么这样写

麻辣烫订货的独有难点不在「算多少」而在「算多早」：干货泡发把订货问题变成了排程问题。多数订货工具（包括现成的进销存）只输出数量，泡发时间全靠人脑记，而人脑在收档时段最不可靠——这条工具的核心价值就是把「要用时间减泡发时长」这个减法固化下来，每晚自动算出「几点开泡」，并分成今晚 / 明早两栏对应真实的工作节奏。

「断货风险」作为订货单的排序键而不是金额，和预警器的逻辑一脉相承：库存撑的天数越少的菜越该先订，跟它贵不贵没关系。天气系数只作用于建议量、不回写菜品库，是个容易忽略但关键的设计——雨天调低的需求一旦污染了日均销量基线，晴天就永远订多了。

验收标准给的是三条可执行的自测用例而不是「界面美观」这类形容词：木耳 2 小时、腐竹 6 小时，一条验正常路径、一条验来不及的拦截。编码代理拿到具体用例，比拿到一段需求描述的出错率低一个量级。

「不预填任何行业数据」「不写死菜品名」是这类工具最容易翻车的两处：预填的「行业平均销量」看起来贴心，实际全是编的数字，用户照着订第一次货就乱套；写死菜品名则让工具在第一家店就无法使用。字大、朴素、单屏，是因为它真实的使用场景是晚上十点、后厨灯下、可能还戴着手套。

变量