社区超市库管：节前仓容测算工具——订货量乘箱体积对上后仓可用容积，占用率三档亮灯，装不下先压哪类货按可存放条件排出来

你是编码代理。请做一个单文件 HTML 的
「节前仓容测算工具」，给社区超市库管用：
节前订货单发出去之前，先算一下后仓装
不装得下。本地运行，不联网、无外部依赖。

定位（按此设计，不做库存系统）：库管最
怕的不是货卖不动，是货到了没地方放——
通道堆货过不了消防检查，冷库门口堆货
温度守不住。这个工具只做体积算术和
分档亮灯：可用容积多少、订货进来后
占用多少、装不下先压哪类。它刻意不做
销量预测——「该订多少」是采购的事，
工具只回答「订了放不放得下」。

三块功能：

一、仓容录入
- 后仓基础：内空长 × 宽 × 高（扣除
  通道后的可用区，工具里给个提示：
  通道按消防要求预留，不折叠计算）
- 层架：每组的宽 × 深 × 层数、组数，
  自动算层架容积
- 冷库：单独录一间（或几间）的容积，
  与常温仓分开算
- 现有占用：可手填「已占用比例」或
  录入现有存货估算，二选一

二、订货测算
- 贴入订货清单（支持直接粘贴表格）：
  品名 / 箱数 / 单箱长宽高（或体积）/
  存放条件三选一：可平置 / 必须上架 /
  必须冷存
- 缺体积只有重量的品项，提供换算框
  （常用箱规预设：如 500ml×24 瓶≈
  0.03m³），预设值可改
- 输出：
  总占用率（常温仓、冷库各一个）
  三色亮灯：占用 <【绿灯线】% 正常；
  【绿灯线】–【红灯线】% 要重排储位；
  >【红灯线】% 必须压单
  分类的占用明细：哪类货占了多少
  通道占用估算：平置货堆超出层架容量
  的部分会堆到通道，工具单独算出
  「通道将被占多少」——这个数就是消防
  风险的直接读数

三、压单建议（装不下时才出现）
- 按固定优先级给「先压哪类」：
  可平置的大体积低周转（整箱饮品、
  卷纸）> 可平置的大体积高周转 >>
  必须冷存（冷库超了冷藏品反而不能
  压，要压先压常温）——冷库超容时，
  建议改成「加订频次、减单次量」而非
  压总量
- 每条建议带一个数字：压【数量】箱
  该品，占用率降到多少
- 只建议到品类和箱数，不替人改单

硬约束：
- 所有计算式显示在结果旁边（占用率 =
  需求体积 ÷ 可用容积），数字要能对上
- 录入数据存 localStorage，可导出导入
  JSON，方便多门店复用
- 预置一份示例订货单（含一个「冷库
  超容」的典型场景），打开即见三色灯
  和压单建议
- 换算预设标注「估算」，不冒充精确

你不许做的：
- 不联网、不接任何库存或订货系统接口
- 不做销量预测、不「智能建议订货量」
  ——订多少是采购的事，工具只管放不放
  得下
- 不做 3D 仓库建模和储位图，这是测算器
  不是 WMS
- 不加账号体系和外部库

为什么这样写

节前仓容的问题从来不是「算不出来」，是「没人提前算」：订货会开完订单就发出去了，货到那天才第一个知道装不下——此时能做的只剩下堵通道，而堵通道的代价（消防检查、冷库门口的货温）全都比压几箱订货贵。所以这个工具的定位写死在「订货单发出去之前」，它不解决怎么放，只解决「下不下这张单」——把仓容从收货日的问题变成订货日的问题。

占用率分三档而不是给一个精确数字，是因为仓容的可用性本来就有糊性：层架上面的空间能不能用、平置能堆多高，各店差异极大。但「七成以下随便放、九成以上必出事」这两条线是共通的，中间档给「重排储位」留出操作空间。通道占用单独算出来，是整个工具最实用的一行：层架装不下的平置货必然溢到通道，「通道将被占多少」就是消防风险的直接读数——把这个数摆在库管和店长面前，压单的讨论就不用吵了。

压单建议的优先级里有一个反直觉的规则：冷库超容时不压冷藏品、改加订货频次。因为常温大件压了只是晚两天到，冷藏品压了就是断货（下次到货前冷柜空着），而「小量多次」对冷库压力立竿见影。这条写死在工具里，等于把老库管的一个经验判断固化成默认选项——工具给建议，但每条建议带数字（压几箱、降到多少），决定权还是留给人。

和排面容量速算是同一族工具，但回答的问题相反：排面工具回答「货架上够不够卖」，这个回答「货到了有没有地方放」——两头的答案拼起来，才是节前「订多少」的完整约束。边界照旧写死：不预测销量、不接系统、不做储位图，工具只守它的那一格。

变量