社区超市理货员：排面容量速算工具——层板长×商品宽算每层面数，配日均销算可撑天数，天天补的品是面位给少了、三天两头剩的品是面位给多了

你是编码代理。请做一个单文件 HTML 的「排面
容量速算工具」，给社区超市理货员用：量一次
货架、答三个问题——每层摆几支、整排装多少、
这排够卖几天。本地运行，不联网、无外部依赖。

定位（按此设计，不做库存系统）：理货员每天
在同一批品上反复补货，从没算过是销量大还是
面位小。这个工具只做几何换算和容量口径：
层板能排几支、整排容量多少、按用户自己录的
日均销折算可撑天数。它刻意不做销量预测——
日均销是用户录入的数，工具只负责除法，预测
模型混进来数字就没人敢信。

三块功能：

一、单品速算
- 输入：层板可用长度（cm，扣掉立柱）、
  商品宽度（cm，量包装最宽处）、层数、
  该品日均销量（件）
- 输出：每层面数（向下取整）、整排容量
  （面数×层数）、可撑天数（容量÷日均销）、
  建议面数（能覆盖【补货周期】+1 天缓冲的
  最小面数，算出来比现有排面大就提示「
  面位不足」，小则提示「面位可让」）
- 单位可切：支 / 瓶 / 袋 / 罐 / 箱，展示
  时带单位

二、货架标签卡（可打印）
- 每个算过的品生成一张卡：品名 / 条码或
  货号 / 面位数 / 整排容量 / 建议补货点
  （容量降到多少该补）
- 打印版一页多卡、黑白可读，尺寸对折后
  贴货架挡板内侧

三、清单与对比
- 算过的品自动进清单，按「可撑天数」
  从小到大排——排最上面的就是天天要补的
  品，清单顶部给一行判断：可撑天数普遍
  低于补货周期的，说明这组货架面位整体
  给少了，找店长要排面；只有个别品短的，
  是那几个品的事
- 清单支持导出 / 导入 JSON

硬约束：
- 所有计算公式显示在结果旁边（可撑天数 =
  容量÷日均销），让用的人看得懂数怎么来
- 日均销允许用户手填一个数，也允许录最近
  几天逐日数取平均——不联网取数，系统
  对接一概不做
- 数据存 localStorage，换电脑可导出导入
- 预置 8-10 个示例商品（含一个「面位不足」
  的典型和一个「面位可让」的典型），打开
  即见三块输出

你不许做的：
- 不联网、不接任何库存或 POS 接口
- 不做销量预测——不拟合、不「智能建议
  订货量」，订货是采购的事
- 不做整店陈列图管理，这是速算器不是
  排面系统
- 不加账号体系和外部库

为什么这样写

「只做几何和容量换算、不做销量预测」是这条工具的承重墙。理货员的真问题往往不是「该订多少」（采购的事），而是「这排货架装得下多少、够撑几天」——一个除法就能回答，且答案对错当场可验（摆一遍就知道每层几支）。一旦工具开始「智能预测销量」，它给出的建议面数就从可验证的几何事实变成了不可验证的模型输出，理货员不敢拿它去跟店长要排面——而这个工具最大的用途恰恰是拿数字去要排面。

「建议面数 = 覆盖补货周期 + 1 天缓冲的最小面数」这个口径把工具从算术器变成谈判筹码：天天补的品，理货员一直以为是销量好，算完发现是三层的排面只装得下一天的量——这类数字拿给店长，比「这个品走得快」有说服力得多。清单按可撑天数排序并把结论分成「整组面位不足 / 个别品的问题」两档，是因为这两种情况的解法完全不同：前者要调排面结构，后者只是个别品挪一格的事。

货架标签卡是让工具落地的一块：算完的数字不回到货架上就只活一晚上。卡上带「建议补货点」，理货员补货时看卡不看系统——对不上系统的店，这张卡就是他自己的最小库存台账。示例数据里特意放一个「面位不足」典型和一个「面位可让」典型，打开十秒就能看懂这个工具到底在回答什么。

变量