早餐店采购订货：原料订货量测算小工具——日均用量 × 周期 + 安全天数，起送线凑单按耐存性推荐

请做一个单文件 HTML 的早餐店原料订货量测算工具，给负责订货的
人用——明天的订货单从算式里出来，不从记忆里出来。

输入（按品项建台账，页面手填）：
- 品项：名称、单位、单价、保质期（天，粉类干货可空）
- 用量：近【N】周的逐日用量记录（手填或批量粘贴，工具算
  日均值与历史最高日）
- 库存：现有数量、在途数量（已订未到，含预计到货日）
- 订货参数：本批到下批的周期天数、安全天数（按断供风险
  自定，每品项可不同）
- 供应商约束：起送金额、主要品项归属哪家

计算与输出：
- 建议订量表（核心）：
  建议订量 = max(0, 日均用量 × (周期天数 + 安全天数) −
  库存 − 在途)
  每行同时给「波动上限档」：用历史最高日用量替换日均重算
  一次——两档并排，断供敏感的品项按上限档订，压库敏感的
  按基础档
- 保质期校验：品项有保质期时，检查「建议订量 + 库存」在
  一个周期内是否用得完——用不完标红「会放到过期」，并
  给出「按到期日用完倒推的最大订量」
- 起送线对照：本单合计金额与起送线对比。不够时：
  a. 列出「加订候选」——已有品项按耐存性排序（保质期长
     的在前，鸡蛋、鲜奶等短保品排除），每行显示加订金额
  b. 不推荐加新品项凑单——凑出来的新品项就是下个月的
     压库
- 打印视图：一页 A4 输出为可直接发给供应商的订货单格式
  （品项 / 数量 / 单位），计算过程全部收起

实现要求：
- 单文件，无外部依赖、无网络请求；localStorage 存台账，
  刷新不丢
- 日均用量只用我录入的历史，不内置任何「经验参考值」
- 波动上限档用的历史最高日必须是我记录里真实发生的，
  不做任何放大系数
- 不做登录、不做云同步

给编码代理的补充说明：
- 逐日用量支持「只记得部分天数」的录入——日均按已录天
  数算，样本天数少于【7】天的品项在结果里挂「样本少」
  角标
- 保质期校验的口径提示放页面上：「到货日 + 保质期 < 下下
  批到货日的量，先别订」

为什么这样写

订货量靠手感的真实机理是记忆的近期偏差：上周断过货的品项这周多订，压在库里的没人记得——所以错误是系统性单边的，库存越积越多、断供却照旧。算式（日均 ×（周期 + 安全天数）− 库存 − 在途）本身平淡，关键在于两档并排：基础档按均值，上限档按历史最高日，让「断供敏感」和「压库敏感」的取舍显式化而不是藏在系数里。工具不替人选担——两档摆着，鸡蛋选上限、面粉选基础，是采购员对自己店最有信息的判断。

两个「早餐店特有」的设计都来自真实的订货现场。起送线不够时的加订候选按耐存性排序，针对的是凑单的随意性：差二十块凑一箱新耗材，这箱耗材就是下月的压库——所以工具只推荐已有品项加量，且短保品排除在外。「会放到过期」的红色校验反向兜底：鲜品订量的算式再对，只要周期内用不完就是错的，这个校验把 FIFO 的常识变成了下单前的强制一问。

「波动上限只用真实发生的最高日、不做放大系数」和「不内置经验参考值」是同一条纪律的两面：这个工具的可信度完全建立在它只说录入数据支持的话上。一旦内置「参考日均」或放大系数，采购员就会在数据不足时依赖那个数字，而它对这家店毫无依据。样本少于 7 天挂角标而不是拒绝计算，是留了诚实的工作空间：新开店、新品项的前几周本来就没数据，标注出来比拒绝服务更符合实际。

变量