零食店采购订货：箱规拆零订货换算工具——进货按箱、库存盘出来是散称斤两、销售按袋按斤三套单位并存，让编码代理做一个单文件工具管住「一箱到底等于多少袋、还够卖几天、该订几箱」

你是编码代理。为零食店的采购做一个单文件 HTML「箱规拆零
订货换算工具」，本地运行、无网络、无外部依赖。

定位（按这个设计，不要做成库存管理系统）：进货按箱、盘点
按斤两、销售有时按袋——三套单位并存，采购订货时全靠心算。
这个工具只做换算和覆盖天数：把任意单位录入的库存和销速
折算成统一口径，算出还够卖几天、该订几箱。它刻意不做
销量预测——销速是用户自己填的数，工具只做除法；一旦混进
预测模型，输出就不敢拿去下单了。

三个功能：

1. 商品档案
- 每个品录入：品名、供应商、箱规（每箱袋数×每袋克重，
  或整箱净重）、进货价（按箱）、计价方式（按斤零售／按袋
  零售）、零售价
- 一条换算链全程展示：1箱 = N袋 = M克 = M/500斤，
  数字旁边永远能看到公式

2. 订货计算
- 录入当前库存（克／斤／袋任填一种）和日均销速（任填
  单位），自动折算成袋
- 输出：可售天数 = 折算库存 ÷ 折算销速；建议订货箱数 =
  （补货周期天数＋安全天数）× 销速 − 库存，再整箱向上
  取整
- 补货周期与安全天数是全局设置，可改
- 可售天数低于补货周期的品自动标红——这是「这周必须下
  单」的线

3. 订货单
- 勾选要订的品，按供应商分组生成订货单：品名／箱数／
  进货金额／合计
- 可打印、可导出 JSON；数据存 localStorage

硬约束：
- 所有换算展示公式（斤=500克 写死在界面里，不藏在代码里）
- 库存和销速的录入框旁永远显示当前被理解成的单位，
  防止斤千克误录——误录直接 2 倍误差
- 预置 8-10 个示例商品，含一个「按斤计价的散称品」和
  一个「按袋计价的包装品」，打开就看到两种口径都在算

不许做的：
- 不联网、不接任何库存或收银系统
- 不做销量预测、不「智能推荐订量」——建议箱数永远只是
  覆盖周期的算术，不是模型输出
- 不做供应商对账、应付账款——那是另一件事

为什么这样写

「只做换算和覆盖天数、不做预测」是这条工具的承重墙。零食采购每次下单的真实困惑不是「该订多少」（那要懂预测），而是「一箱到底顶几天」——一个除法就能回答，而且当场可验证（货到了数一数）。一旦工具开始「智能预测销量」，建议箱数就从可验证的算术变成不可验证的模型输出，采购反而不敢照着下单。工具的全部价值在于给一个没人能抬杠的数字。

单位录入框旁实时显示「被理解成的单位」这个细节，防的是零食店换算事故里最贵的一种：斤和千克录混，直接 2 倍误差，方向是断货还是压库全看运气。三套单位（箱／袋／斤两）并存是零食店的行业常态——散称区按斤卖、包装区按袋卖、供应商按箱送——工具不是强制统一录入单位，而是任填、内部统一，这才是每天真实使用得下去的形态。

建议箱数的公式刻意写成「补货周期＋安全天数」的覆盖算术并整箱向上取整，而不是「最优库存」之类的词：零食供应商箱规不齐（有 24 袋的也有 40 袋的），整箱取整是物理现实，公式里多加任何一层「优化」都会让采购看不懂这个数怎么来的。按供应商分组生成订货单，是因为下单的真实动作是「给 A 家的业务发一张单」——工具的最后一步必须落到这个动作上，否则算完还要手抄一遍。

变量