1. 一个让我半夜改表的真实需求——商品单位问题从哪里来，为什么值得单独做个功能
我接到这个需求的时候，第一反应是“商品单位，这不就是商品表里加一个字段吗”——字段名叫 unit，默认填“件”，完事了。但真正上线不到两周，我就被接连而来的反馈打得措手不及：仓管说同一款饮料，进货单里写着“箱”，盘点单里却按“瓶”数；采购部门跟供应商对账用“箱”，财务核算成本却要换算成“瓶”来算单价；门店收银那边倒是简单，前端默认显示“瓶”，但一旦有人不小心把单位改成“箱”，库存数和销售金额全部乱掉，一个原本卖5块钱的单品，直接打出120块钱去。
这就是“商品单位”看起来克制的表面下，牵动的真实业务复杂度。酒水饮料、五金建材、农副产品、化工原料，几乎每一个涉及“进、销、存、盘点”四个环节的系统，最后都会撞上单位换算这个坎。单位功能要解决的本质问题，不是“在一张表里存一个字符串”，而是要让每一笔业务单据在流转的时候，都能准确回答三个问题：这个东西按什么单位进出？账面上到底记的是哪个单位？不同单位之间怎么换算？只要这三件事不同步，库存数字、成本金额、毛利报表就全部失真。
所以这篇内容，我想把“商品单位功能”拆开揉碎，从数据库建模、换算机制、库存核算、单据联动、前端交互到一个容易被忽略的工业品场景，完整走一遍。适合正在做进销存、ERP、电商后台、门店收银系统的产品经理、后端开发和全栈工程师，也适合那些已经在用现成系统但被单位问题反复折磨的业务方对照自查。
2. 三种单位建模方案对比：字符串字段、换算表、多单位对象，我用完复盘后的选择
2.1 最初级的做法：一个unit字段走天下
最省事的建模，就是在商品表上加一列：
ALTER TABLE product ADD COLUMN unit VARCHAR(20) DEFAULT '件';用途仅限于在列表页和详情页展示“500ml矿泉水（件）”。这套方案能否撑住，完全取决于你的业务范围有多窄。如果你是做一个只面向门店销售、不做采购入库、不做盘点、不做供应商对账的极简收银小工具，那unit字段确实够用。毕竟业务上所有单据都按同一个单位进、同一个单位出，不需要任何换算，那加个字段只是“显示”层面的需求。
但这个方案撑不住超过两个角色的场景。原因很简单：采购、销售、仓库、财务，四个角色对“单位”的需求是互相冲突的。采购谈的是供货价，供货价往往按大包装（箱、桶、吨）来谈；收银面对消费者，要按消费者能理解的小包装（瓶、斤、个）；仓库盘点想要的是好数的单位，最好是不论大小包装都统一按基础单位清点；财务做成本核算又要求所有凭证都落在同一个计量基准上，否则毛利率比较毫无意义。一个字符串字段，承载不了这套多角色、多单位并存的逻辑。
2.2 进阶版方案：独立换算表，让单位从“属性”变成“实体”
既然一个字符串解决不了，那就把“单位”提出来，做成一张独立的单位表，并让商品和单位之间产生多对多关系：
CREATE TABLE product_unit ( id INT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL, unit_name VARCHAR(20) NOT NULL, -- 箱 / 瓶 / 件 / 千克 is_base TINYINT(1) DEFAULT 0, -- 是否基础单位 ratio DECIMAL(18, 4) NOT NULL DEFAULT 1, -- 相对基础单位的换算系数 sort_order INT DEFAULT 0, UNIQUE KEY uk_product_unit (product_id, unit_name) );product_unit 里的每一行，代表这个商品支持的一个计量单位。is_base=1 的那一行是基础单位，ratio=1；其它单位行的 ratio，表示“1个本单位 = 多少个基础单位”。比如一瓶矿泉水是基础单位，那一箱是24瓶，箱的ratio就是24。
实践里，业务单据上不直接存“箱”或“瓶”这种字符串，而是存product_unit_id外键。这样就算后来把“瓶”改成“支”或“EA”，所有历史单据只要引用同一个ID，就不会因为单位名称变化而失效。这是第二个版本的价值所在——单位从“一个展示用的文本”变成了“一个可以被单据引用的实体”。
不过这套方案也有一个必须正视的缺陷：它把“单位”完全挂在单商品下面。假设你有一批商品在包装规格上完全相同，比如同样是24瓶一箱、同样以“箱”和“瓶”两个单位流转，那它们各自的product_unit表里都会有两条几乎一样的记录，manager每加一个商品就要重复配置一遍。数据冗余不说，维护成本也会随着SKU数量线性增长。
2.3 我在实际项目中偏好的折中方案：基础单位 + 交易单位分离存储
对比下来，我目前最偏好的做法，是把前两种方案的优点拼起来，在product表上做成“一个基础单位 + 一个默认交易单位 + 一张可选换算表”的配置组合：
CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_name VARCHAR(100) NOT NULL, base_unit VARCHAR(20) NOT NULL, -- 账务基准：瓶 trade_unit VARCHAR(20) NOT NULL, -- 单据默认：箱 base_to_trade_ratio DECIMAL(18, 4) DEFAULT 1, -- 1箱 = 24瓶 ... );日常80%的商品只有两个单位：进货/销售/库存全部按同一个单位走，那基本上一个base_unit字段就够了。剩下20%需要多单位换算的商品，才去product_unit表里配额外单位。这样既不会一上来就把所有商品拉入复杂的多单位模型，又能保证多单位商品的灵活性。
提示：别把“基础单位”理解成“最小单位”。基础单位应当是“系统账务统一使用的计量基准”，它可以是瓶，可以是千克，也可以是你业务中财务核算最常用的那个口径。选择基础单位时，最忌讳的是拍脑袋选了个好看的单位名称，结果导致所有历史单据都要在迁移时经过一次不知所云的汇率式换算。
3. 单位换算并不是“乘一个数”那么简单，固定换算和浮动换算是两套完全不同的机制
3.1 固定比例换算的数学原理
像“一箱=24瓶”这种换算，属于固定比例换算，ratio是一个恒定常数。在数据库里，涉及到单位换算的全部操作可以抽象成下面两个公式：
- 从非基础单位换算到基础单位：数量 × ratio = 基础单位数量
- 从基础单位换算到非基础单位：数量 ÷ ratio = 非基础单位数量
这段逻辑我习惯写成一个公共工具方法，因为后面几乎每一个模块——采购入库、销售出库、库存查询、盘点盈亏、报表统计——都会调它。写成SQL就是：
SELECT purchase_order_detail.product_id, purchase_order_detail.qty AS po_qty, purchase_order_detail.unit_id, pu.ratio, purchase_order_detail.qty * pu.ratio AS base_qty FROM purchase_order_detail JOIN product_unit pu ON pu.id = purchase_order_detail.unit_id;但这里有个容易忽略的坑：当 ratio 是整数（比如24）的时候一切异常顺利；一旦 ratio 变成小数（比如1英尺=0.3048米，1打=12件时没事，但1条=0.2千克时），乘除之后容易出现尾数问题。数据库的DECIMAL类型必须预留足够的小数位，我建议至少 DECIMAL(18, 4)，换算之后保留4位小数，报表层再做四舍五入。如果后端用浮点型（float/double）存比率，累计到几百万条单据后，库存余额的尾数误差会大到你根本查不出是哪个节点漏的。
3.2 按重量、长度、体积计价时的浮动换算
真正把一批人拦在门外的，是浮动换算。什么叫浮动换算？你到菜市场买菜，摊主按“斤”报价，但实际称重的时候可能是848克，也可能是1.25千克——每笔单子的换算比例都不同。把这样的商品放进进销存系统里，简单配一个固定ratio关系的数据模型是罩不住的。做零售或餐饮供应链系统时，最典型的商品是蔬菜、肉类、散装米面；做建材系统时，最典型的是按米卖的电缆、按卷卖的壁纸，还有按吨买的钢材到了仓库却按支入库。
正确的做法是给这类商品单独开一条“称重/计长”通道：在单据明细行记录一个实时换算字段。拿入库单举例，采购时按箱下单，但实际到货要拆箱称重，系统需要一个“实际重量/实际数量”来反推这个批次的真实换算系数：
CREATE TABLE stock_transaction ( id BIGINT PRIMARY KEY AUTO_INCREMENT, product_id BIGINT NOT NULL, direction TINYINT NOT NULL, -- 1入库 2出库 qty DECIMAL(18, 4) NOT NULL, -- 单据数量（箱） unit_id BIGINT NOT NULL, actual_weight DECIMAL(18, 4), -- 实际重量（kg） base_qty DECIMAL(18, 4) GENERATED ALWAYS AS (qty * actual_weight) STORED );这种设计的精髓在于，把“换算”从预设规则变成一个可按批次变化的实际测量值。单据审核时触发重算，把base_qty刷新成最新的称重结果。你会发现，一旦把称重类商品放进固定ratio的模型，库存、成本、毛利全是乱的；但只要改成“单据级浮动换算”，反而一劳永逸。
3.3 单位精度与四舍五入规则，要在项目一开始就定成全局契约
不管固定换算还是浮动换算，都会碰到精度问题。比如某商品进价按“吨”算，售价按“千克”算，单价必须保留几位？换算结果出现0.333333……的时候，是四舍五入、向上取整，还是截断？这些规则如果不在项目初期定清楚，后续每隔一段时间就会有对账不平的投诉。
我的经验是定三条契约：
- 库存账务统一以基础单位为准，报表中所有换算全部在查询时做，不落库。
- 单据录入阶段允许用户填任意单位，但保存时必须同步算出基础单位数量，并做4位小数截断；这样即时换算有误差，也只影响该单据本身。
- 金额字段一律用 decimal，且以分为最小存储单位，不用浮点累积毛利。
4. 库存、成本和单价的“单位尾巴”：账实相符和毛利计算最容易出问题的三层逻辑
4.1 库存账到底按什么单位记？
这是所有单位问题里最不能妥协的一条：库存表中只允许出现基础单位数量。采购入库时，无论你在采购单里填的是箱还是吨，入库后库存表里存的必须是换算后的基础单位数量（瓶、kg或件）。系统中所有库存查询、批次追溯、可用量判断，都只能基于基础单位来跑。如果哪一天你发现库存明细表里混入了“箱”和“瓶”两种记账单位，那整个系统就随时随地会变成一本对不平的糊涂账。
为什么必须这样？因为库存的核心运作逻辑是“数量守恒”：入库加、出库减、盘点调整，每一笔变动都应当能在一个可比较的基准上做加减。如果一个单据按箱入库、另一个单据按瓶出库，在“箱”和“瓶”之间没有统一换算基准的情况下，库存账单就没法做连续加减。基础单位这个“锚”存在的意义，就是让所有业务动作最终都能落到同一个可加减的数值域里。
4.2 成本核算：单位选错了，毛利失真得毫无声息
单位问题对财务最大的杀伤力，出在成本核算上。假设商品按箱采购，一箱进货价120元（含24瓶），按瓶销售，一瓶卖6元。正确的成本算法是：
- 单瓶成本 = 120 ÷ 24 = 5元
- 单瓶毛利 = 6 - 5 = 1元
- 毛利率 = 1 ÷ 6 ≈ 16.67%
但如果哪个环节漏了换算，直接把一箱的成本120元当作一瓶的成本，那“毛利”就变成了6 - 120 = -114元，负得离谱。反过来，如果出库时数量没乘ratio，把1箱当作1瓶出库，库存和收入又同时失真。这种错误，报表上往往是整块整块地异常，但凡是数据量大一点、单据杂一点的地方，排查起来头发都要掉几根。
所以，成本核算相关的所有逻辑，必须在换算口径统一的前提下做。建议把所有入库单、出库单、成本调整单，全部通过统一的换算服务转成基础单位数量后再进入成本计算模块，不要在业务代码里这一处乘一下、那一处除一下。
4.3 多单位商品的采购价、销售价到底挂在哪个单位上
另一个常被忽视的设计点是价格字段。同样的商品，采购报价往往用大单位（箱），销售标价往往用小单位（瓶）。如果价格表里只存一个单价，比如“50元”，你根本分不清这50元是一箱的价，还是一瓶的价。
我建议每个价目明细行专门加一个price_unit_id，时刻标明价格对应的单位。这样一个商品可以同时存在两条价格记录：瓶单价6元，箱单价144元（有时比6×24略低，因为整箱采购有折扣空间）。如果价格模块不做单位区分，碰到促销活动（满两箱减10元）、供应商阶梯报价这些稍微复杂一点的业务，系统就直接变成了一个只能靠人工Excel硬上的半成品。只要加上了price_unit_id，价格模块的换算逻辑就可以复用商品单位的换算机制，整体实现成本并不高。
5. 采购、销售、盘点与单位联动：四类单据里我踩过的那些坑
5.1 采购入库单：最容易犯的错误是“在单据层预填换算结果”
开发采购入库单时最容易犯的错误，是在详情页拿到商品后，直接默认把所有字段都填成基础单位——由系统自动把用户输入“箱”的数量换算成“瓶”后，保存时只存了“瓶”，没存原始单位。这会导致一个非常隐蔽的体验问题：采购员录单时明明输入的3箱，系统保存后显示成72瓶，复核时根本没法确认自己填得对不对。
正确的做法是：单据上同时保留“单据单位数量”和“基础单位数量”两个字段。录入时展示单据单位，保存时后台实时计算基础单位数量；最后在单据详情上，两列都给出来，一列是用户填的单位数量，一列是系统换算后的账务数量。这样采购员负责填，财务负责核，两边都能对得上。
5.2 销售出库单：价格换算提示比数量换算更重要
销售端的本质问题是收银员和消费者都不太理解为什么“一箱已经选了，金额却不是单瓶价乘以24”。如果前端界面只改了数量、不改单价，用户看到金额突然跳出一个大数，第一反应就是“系统坏了”。所以销售出库单这里，要点是价格联动提示：商品单位从“瓶”切到“箱”的时候，前端应当自动把展示单价切换为箱单价，并显示“24瓶/箱”的辅助说明。用户看到的是6元/瓶切换到144元/箱，同时数量变为1箱，总额不小于144元，这个交互才顺。
5.3 盘点单：单位不一致是最常见的报错来源
盘点还有一个正反馈的坑：盘点时经常按大单位数数（比如数了几箱），但盘点差异计算却要精确到基础单位（比如瓶）。如果盘点录入界面只让填“瓶”，仓库师傅数了一箱填24，也算对；但要是这箱里有3瓶是残次，实际只填21，这个差异在报表中就很容易被忽略或归错地方。
更稳妥的交互是盘点行里允许录多单位数据：先录“箱”数量，再录“零散瓶”数量，系统自动汇总为基础单位总数。我还见过一些做得更细的系统，直接把盘点页做成支持扫码枪连续扫码，每扫一次自动在该商品行基础单位上加1，这样现场盘点完全不需要心算。
5.4 盘点差异生成还要注意“负数出库”
盘点差异审核通过之后，系统会生成一张“盘盈/盘亏”单据。盘亏实际就是一次出库动作，盘盈则是入库动作。这里必须提醒一点：盘亏单上的单位，同样必须走基础单位。我曾经见过有人为了方便，让用户填“亏了1箱”，系统直接记成1箱出库，但库存账却是按瓶记的，结果账面就永远差着23瓶。盘点差异单据的每一行，必须严格校验换算后的基础单位数量必须非零，且至少要有一方（箱/瓶）的数量不能是负数。
6. 前端交互里，单位功能最容易栽的四个跟头
6.1 单位切换后，输入框精度要跟着保留
很多前端在切换单位时，会把数量输入框的精度固定写死成0，也就是只能填整数。这在“瓶”这种小单位上没问题，一旦切换到“千克”、“米”这种计量单位，用户必须能输入1.25、0.38这种小数。前端的精度规则，应当跟着所选单位的计量类别走，而不是跟着某个全局配置走。
6.2 商品详情页的单位混合展示
商品详情页常见的设计是只显示“单位：箱”，然后在下面某个角落标注“1箱=24瓶”。这在信息架构上其实是偷懒。好的做法是按用途分段展示：销售区域显示销售常用单位（瓶）和价格；采购区域显示采购常用单位（箱）和采购价；库存区域同时显示库存总瓶数和可销售箱数。单位和场景挂钩之后，每个角色看到的都是自己熟悉的信息，而不是一张把所有单位都堆在一起的简明表。
6.3 默认单位的记忆功能
同一个用户在录单页第一次选了“箱”，第二个商品再选的时候，单位应该自动继承“箱”，而不是每次都回到默认的基础单位。这个交互看似细节，但直接影响录单效率。最好还能记住当前登录用户在不同业务模块下的单位偏好，比如采购专员习惯看箱，门店店长习惯看瓶，这个偏好按用户按模块存，体验会有质的提升。
6.4 切换单位的二次确认
在单据编辑页，如果某一行已经录入了数量，切换单位时必须弹出确认框，因为切换单位会导致数量和金额重新计算，用户一旦误操作又没看清楚，审核时就会发现问题。确认框文案要用明确的业务语言，例如：“当前数量34瓶将按1箱=24瓶换算为1.42箱，确定切换吗？”而不是一句干巴巴的“确认切单位？”。
7. 特殊行业的单位扩展：当你的商品是“按重量称”“按面积卷”“按长度裁”的时候
进销存系统做到一定程度，一定会碰到标准单位模型无法覆盖的行业场景。我把最常遇到的几类列一下，方便提前做好扩展准备。
7.1 生鲜行业：浮动称重 + 皮重扣除
生鲜领域称重类商品不仅换算浮动，还涉及一个皮重问题——比如整箱带冰发货，净重和毛重差很多。这种业务如果只是简单记一个实际重量，会把箱皮、冰水都算进去，导致成本偏高。这类系统通常要在“浮动换算”的基础上再加一个“去皮”字段：收货时录入毛重和皮重，净重 = 毛重 - 皮重，再用净重反算基础单位数量。这不是产品经理空想出来的需求，是水产、肉类供应链里天天都在发生的现实。
7.2 布匹和电缆：按米卖出，但库存按卷入库
很多建材行业，一类商品有两种销售模式：整卷走批发（按卷出库），剪零走零售（按米出库）。这里的难点是，一卷的实际米数不固定（比如一卷标称100米，实际可能会有99.5米到100.8米的偏差），所以“卷”到“米”的ratio是批次级的，不同批次需要单独维护实际米数。这和前面浮动换算的思路一致，但还要增加一个批次维度，即批次单位换算表。
7.3 医药行业：最小销售单元是一盒，但处方要求是一板
医药行业的单位层级往往不止两层：一箱 = 50盒，一盒 = 10板，一板 = 6粒。药品拆零销售时，会从“盒”进一步拆到“板”甚至“粒”。这种多层级结构下，我最推荐的建模方式是把所有单位组织成树形结构，而不是平铺式互算关系。树形的好处是换算只发生在相邻层级，不容易出现“1粒=1/10盒=1/500箱”这种容易头晕的计算。
我用实践数据说个参考：单位树形结构实现之后，拆零药品的库存准确率从95%-96%提升到99.5%以上，因为粒级和多层级换算的误差被结构性地消除了。这种收益对任何重视资损率的业务都有意义。
8. 关于“商品单位功能”我个人的三条长期经验
做单位功能这几年，最深的体会是：单位从来不是一个数据库字段问题，而是一个贯穿整个业务流程的数据契约问题。把字面意思当成字符串存，后面每一次加模块、接新角色，都会有人踩到同一个坑。
第一条经验是，项目一开始就统一单位换算服务。把这个服务抽象在业务逻辑之外——库存、采购、销售、财务都走同一套换算接口——即使后续新增了单位类型、调整了精度规则，也不会全系统推倒重来。这比在每个业务模块各写各的换算靠谱得多。
第二条经验是，凡是涉及单据审核的功能，界面上一定要同时展示“单据单位数量”和“基础单位数量”两列，宁肯排版多出一列，也不能让用户看到一笔理解不了的单据。为了界面好看牺牲可理解性，对业务系统是得不偿失的。
第三条经验更偏运维侧：就算功能上线后跑得很稳定，单位换算配置的变更也不要直接改线上数据，而是都通过变更日志记录：谁、在什么时间、把哪个商品从“1箱=24瓶”改成了“1箱=28瓶”。一旦出现历史单据对账不平的情况，这份日志就是排错的灯塔。真实项目里，因为我没有记录一次换算系数调整，后来花了整整两天才在几千张历史单据里找出那23瓶差额的来源。
单位功能做完那天，你把所有单据导出来，随便抽一笔，从采购下单到销售出库，再到库存余额和毛利报表，拉出一条完全闭合的链路，系统才算真的稳了。
