去年年底，我帮一家做进口食品的电商公司做数据诊断。他们用着某头部 SaaS ERP，SKU 大概 3000 个，其中 60% 以上涉及称重入库和分装出库。财务总监说系统里的账和仓库的实物永远对不上，每个月的盘盈盘亏差异能到 3 到 5 个百分点。IT 团队排查了三个月，权限、接口、操作流程全查了一遍，没找到问题。最后我发现，问题出在一个几乎所有人都觉得“根本不是问题”的地方，克与千克之间的换算舍入。他们入库用的是千克，最小精度两位小数；出库用的是克，整数。入库 1 箱 0.55 公斤的坚果，系统存成 0.55，分装成 500 克的小包装出库时，系统反算需要扣减 0.5 公斤，结果流水跑完之后，系统里还剩下 0.05 公斤。1000 单跑下来，账面库存比实物多出了整整 50 公斤。这就是我今天要讲的核心问题：多单位换算场景下克与千克之间的舍入误差，不是精度问题，是架构设计问题。
我见过太多团队把多单位换算的舍入误差当“偶发 bug”处理。开发接到工单，把小数位数从 2 位改成 4 位，测试环境跑通，发版，完事。然后三个月后同样的问题换一个 SKU 又冒出来。为什么？因为这不是精度够不够的问题，而是你让计算机在错误的时间节点做了舍入决策。
先给结论，后面我会一层层拆开讲：
我来还原一个真实的入库场景，让你看清楚误差到底是怎么产生的。
假设你是某食品仓库的库管，供应商送来一批进口巧克力，规格是每箱 0.48 千克。你的系统设定：
入库 1 箱，你在系统里录入 0.48 千克。系统存进库存余额的是 0.48。这个数字本身看起来没问题，但它的真实物理含义是 480 克。注意，0.48 千克恰好能被 2 位小数精确表达，所以这笔单子暂时没问题。
再入库一箱，这次是 0.37 千克，真实物理含义是 370 克。存进系统，0.37。
库存余额：0.48 + 0.37 = 0.85 千克，即 850 克。这个计算也没问题，因为 0.85 恰好能被两位小数表达。
现在客户下单要 500 克巧克力。出库单单位是克，你输入 500。系统要扣减库存，它必须把 500 克换算回千克，即 500 ÷ 1000 = 0.50 千克。库存余额变成 0.85 – 0.50 = 0.35 千克。
物理仓库里剩下的是 850 – 500 = 350 克，也就是 0.35 千克。锁死了，完美匹配。
好，现在换一个场景。第三批入库，数量是 0.33 千克一箱，一连入了 3 箱。0.33 × 3 = 0.99 千克。系统库存余额变成 0.35 + 0.99 = 1.34 千克。物理库存是 350 克 + 990 克 = 1340 克，1.34 千克。完美。
现在客户下单，又是 500 克出库。扣减库存 0.50 千克，余额 0.84 千克。物理库存 1340 – 500 = 840 克，0.84 千克。还是完美。
你是不是觉得我在故意绕圈子？因为上面所有数字都恰好能被 2 位小数精确表达。问题出在那些不能被精确表达的数字上。
换一个真实的入库数字：某供应商送来的蜂蜜，每罐净重 0.375 千克。这是一个在食品行业极为常见的规格。你需要入库 10 罐。
物理总重：0.375 × 10 = 3.75 千克 = 3750 克。
你在系统里怎么操作？大部分系统的入库界面只给你 2 位小数的输入框。0.375 输入不进去，你只能输 0.38 或者 0.37。如果你选四舍五入，0.38。那么系统记录的入库是 0.38 × 10 = 3.80 千克。
账面库存：3.80 千克。实物库存：3.75 千克。差额 0.05 千克，即 50 克。这才 10 罐。
如果供应商一次性送来 2000 罐呢？账面 760 千克，实物 750 千克，差额 10 千克。这个误差不是系统算错，是你在入库那一刻就被迫做了一个舍入决策，而你没有其他选择。
你可能会说，那我不四舍五入，我统一向下取整，输 0.37 入库。这样账面 3.70 千克，实物 3.75 千克，账面少了 0.05 千克。表面上看库存变少了，财务成本核算时可能早早就触发“盘亏预警”，导致采购部门提前补货，最终形成冗余库存。这两种方向都会导致决策误判，只是表现形式不同而已。
更恐怖的情况出现在出库环节。假设系统在入库时已经四舍五入存了 3.80 千克（实物 3.75 千克）。现在有一个订单，客户要买 250 克 × 15 份 = 3750 克。
出库单以克为单位，操作员输入 3750 克。系统换算：3750 ÷ 1000 = 3.75 千克。系统扣减库存 3.75 千克。
账面库存余额：3.80 – 3.75 = 0.05 千克。实物库存余额：3.75 – 3.75 = 0 千克。
这下就更精彩了：库房里明明已经空了，系统还显示有 0.05 千克库存。财务做月结的时候，这个 SKU 永远清不掉，库龄越拉越长，最后被采购系统标记为“滞销库存”，但实际上根本没有实物。这种幽灵库存我见过太多，一个仓里动辄几十上百个 SKU 挂着零点零几的余额，加起来几十万。
做过多系统对接的人都知道，长度单位（米、厘米）、体积单位（升、毫升）之间的换算是 10 的整数次幂，大多数日常数值在这些单位之间的转换可以被二进制浮点数较好地近似。但重量单位中，克与千克 1:1000 的换算比例，配合千克 2 位小数的业务习惯，形成了一个极其糟糕的精度三角。
我们来算一笔账。千克保留 2 位小数，意味着最小可表达的单位是 0.01 千克，即 10 克。当你的入库数量是 0.375 千克（375 克）时，375 不是 10 的整数倍，所以它在千克的两位小数体系里永远无法精确表达。
这跟浮点数精度没关系。就算你用定点数 decimal(10,2) 存，0.375 存进去还是会被截断或舍入成 0.37 或 0.38。这是显示精度和物理精度之间的不可调和矛盾。
我在多个项目里做过一个简单的统计：取某中型电商仓库一个月的入库记录，筛选单件重量在 0.01 到 1 千克之间且以千克录入的 SKU，将近 23% 的入库明细存在小数点后第 3 位舍入的问题。一个仓库一个月产生 4 万条入库记录，其中 9200 条有舍入，平均每条偏差约 4 克，月度理论偏差约 36.8 公斤。这是一个非常保守的估算，实际仓库的 SKU 密度更高、进出频率更高，偏差只会更大。
还有一个常被忽视的因素，就是分装场景。食品、保健品、化妆品、工业零配件领域大量存在“大包装拆小包装”的业务。入库是一个大桶、大袋，以千克计；出库是小瓶、小包，以克计。每一次分装都相当于做一次单位换算，如果分装环节也做了舍入，二次舍入会让误差在同一个 SKU 身上反复放大。这种误差不是线性的，是阶梯式跳变的。
我在过去的项目里见过至少五六种“修复方案”，绝大多数是头疼医头，下面逐一拆解。
这是最常见的所谓“根治方案”。开发把重量字段从 decimal(10,2) 改成 decimal(18,6)，信心满满地说现在精度足够高了，误差不会再出现了。然后测试一跑，入库 0.375 千克，存成 0.375000；出库 375 克，换算 0.375000，完美匹配。
问题在哪？在生产环境里，操作员录入的不是 0.375，是 0.38。因为他面前的入库界面最多给他 2 位小数的输入框。你把数据库精度提高到 18 位也没用，误差在 UI 层就已经发生了。除非你同时改造所有录入端，把千克单位的输入精度强制提高到 3 位小数以上，但这个改变会直接影响所有操作员的工作习惯，培训成本和出错率都会上去。
有的团队说，那简单，入库不用千克，统一用克，整数，存进数据库也是整数，总不会有舍入了吧？
方向是对的，但落地有问题。你让供应商送货的时候提供“克”为单位的送货单？供应商的 ERP 输出格式是千克，3 位小数的千克。你让人家改？不现实。所以这个方案的本质压力转移到了数据录入环节，最终还是需要有人在某个环节把 0.375 千克乘以 1000 得到 375 克，然后录入系统。这件事如果是人工做，算错一次就是 1000 倍的偏差，比原来的舍入问题还严重。
这个思路好一点，但仍然不够。典型的做法是：数据库存 decimal(18,6)，前端展示时对千克做 2 位小数格式化。这确实解决了存储精度的问题，但没有解决业务决策时点的舍入。
举个例子：出库单需要显示“本次出库重量（千克）”，如果格式化显示为 0.38 千克，但实际上扣减库存时用的是 0.375000，那这张出库单打印出来之后，客户如果拿回去对账，他就会问：“为什么你们的出库单写 0.38，我算下来是 0.375？”这个不一致会造成大量的客服解释成本。
舍入本质上是一个业务协议问题，不是一个纯技术问题。
我有一套很简单的诊断方法，已经验证了超过 20 次，客户的 IT 团队拿去基本能在半天内定位到问题。
写一条简单的 SQL，查询库存余额表中，重量字段的小数部分不等于 0、且绝对值小于某个阈值（比如 0.1 千克）的记录。如果查出大量 SKU 挂着 0.01、0.02、0.03、0.07 这种尾巴，而且长期没有被清零，大概率是舍入误差导致的幽灵库存。
这里有个经验值：正常业务产生的合理库存余额，其小数分布是随机的，不会集中在某个特定区间。但舍入误差产生的尾巴，通常聚集在 0.01 到 0.09 这个范围，因为这是千克两位小数下最小可表达的单位区间。你可以对比这些“尾巴 SKU”的数量和占比，如果超过总 SKU 数的 5%，就必须警惕。
选一个重量为 0.375 千克、0.625 千克这种典型的“3 位小数”SKU，从采购入库单开始，追踪每一笔库存流水：
把这五个数字拉出来对比，在任何一个环节出现四舍五入的痕迹，这个链路就是有问题的。我经常看到的情况是，入库单显示 0.38，库存流水存 0.38，但出库单按克显示 375 克，库存流水扣减时却用了 0.38 千克（而不是 0.375 千克）。这个瞬间，误差就被固化了。
这一步是最重的，但也是最有说服力的。把指定时间段内所有涉及该 SKU 的入库总和、出库总和拉出来，用数学公式验证：
期初库存 + 总入库 – 总出库 应该等于 期末库存
如果不相等，差值在小数点后两位，而且差值可以被 0.01 整除，那你基本可以确定就是舍入误差。我见过最夸张的一个 case，单个 SKU 一年产生的舍入偏差高达 7.8 千克，该 SKU 全年总吞吐量才 300 公斤，偏差率超过 2.5%。
我直接给出生产环境可落地的方案。不搞学术，只讲能用的。
这是最彻底的方案，也是我目前在推荐给所有新系统、以及有条件做重构的老系统的最优解。
核心逻辑只有一句话：系统内部一切重量相关的存储和运算，全部使用最小计量单位（克）的整数。千克只是用户界面上一个展示格式，数据库里永远不存以千克为单位的带小数点的数字。
具体落地路径：
这个方案的代价是：所有涉及重量的接口都要改。但好处也是根本性的：你在任何一个数据节点都不会丢失精度。
有人会问，最小单位一定要用克吗？如果你的业务涉及毫克级别的称重（比如贵金属、精细化工），那就用毫克或者更小的单位，原则是一样的：内部用整数，外部格式化。
如果你的系统已经成型，做全链路 integer 重构成本太高，那么可以采用这个折中方案。思路来源于财务会计的“差异处理”逻辑。
具体做法：
这个方案有一个天然的适配场景：电商 ERP 与第三方仓储 WMS 对接。很多第三方仓只接受整数克或者特定格式的重量数据，你在传输出库指令时不可避免要做舍入。这时候把舍入差异单独记录，月底拉出来和财务一起核销，是最务实的做法。
我并不推荐每个系统都走这条路，因为舍入差异池本身也有管理成本。但如果系统架构短期内改不了，这是一个可接受的止血方案。
讲一个我亲自处理过的案例，这个案例比较极端，但能非常直观地说明问题有多严重。
客户是一家做跨境保健品贸易的公司，商品从新西兰进口，在国内的保税仓做分装，然后通过多个电商平台销售。单品是某品牌的蜂蜜，规格是 500 克/瓶，但海外供应商的供货规格是 23.5 千克/桶。每桶理论可以分装成 47 瓶（23.5 × 1000 ÷ 500 = 47）。
但他们的系统在入库环节是以千克为单位，保留 2 位小数。23.5 千克是可以精确表达的，没问题，存进去就是 23.50。
问题出在分装环节。分装时需要在系统里扣减大桶库存，同时增加小瓶库存。系统里扣减大桶的逻辑是：每分装一瓶，扣减 500 克，即 0.50 千克。
分装 47 瓶，扣减总量：0.50 × 47 = 23.50 千克。
看起来完美平衡？等等。
实际操作中，仓库并不会一次性把整桶全部分装完。今天是 10 瓶，明天 15 瓶，后天 22 瓶。每次分装都是一次独立的库存事务。问题在于，他们的系统在每一次分装事务中，都会把扣减重量舍入到“千克保留 2 位小数”。0.50 当然没问题，但如果有一天他们要分装一个非标准规格呢？
真正引爆问题的是一次退货。有客户退回了 1 瓶，仓库收到后做了退货入库。退货入库的重量录入是克，录入 500 克。但系统在处理退货入库时，换算逻辑写成了 500 ÷ 1000 = 0.5，然后存入一个 decimal(10,2) 的重量字段，存储值为 0.50 千克。
这里本身没毛病。真正出毛病的是一个极其隐蔽的设计：他们的分装模块和退货模块调用了不同的换算函数。分装模块用的是乘以 0.001（即除以 1000），退货模块用的是除以 1000.0。在 Java 的 double 运算下，这俩结果在二进制层面差了小数点后第 16 位。平时被 decimal(10,2) 截断后看不出差异，但在某一天的某个并发事务中，锁等待导致其中一笔流水的舍入方向发生了改变。
最终结果是：一桶 23.5 千克的蜂蜜全部分装完毕并完成所有退货处理后，系统显示大桶的库存余额为 0.01 千克，而不是 0。
这 0.01 千克被财务系统读走，生成了一个价值几块钱的“在库库存”，并在某次税务核查中被挑出来要求提供实物证据。客户拿不出这 10 克蜂蜜，仓库也找不到，最后被税务机关质疑库存管理是否合规。虽然最终没有形成实质性处罚，但前后折腾了三个月，IT 团队、财务团队、法务团队全部卷入。
从系统设计的角度来看，这 10 克蜂蜜根本不应该是问题。但正是因为它“太不重要了”，所以从来没有被认真对待过。
不是所有企业都需要立刻做全链路整数重构。我根据企业规模和业务复杂度，给一个分级建议。
这类企业暂时不需要做架构级改造。但至少要做两件事：
这就是我前面提到的那种“最容易出事”的企业。建议：
这类企业没有借口，必须做全链路整数存储。而且不能只做重量，长度、体积、数量，所有涉及单位换算的度量字段都要统一评估。一个大型企业的库存系统，一天可能有几十万条流水，任何一条流水上的任何一次舍入，乘以时间，都会变成真金白银的损失。
实施建议：
我写这篇文章的目的，不是让所有人回去把系统大卸八块、全部重构成整数存储。任何技术方案都有成本，关键是在精度、成本和业务可接受度之间找到平衡点。
我见过一个做生鲜配送的公司，他们选择不改造系统，而是在财务月结时，由财务手工录入一张“舍入差异调整单”，把因为克与千克换算产生的差异一次性冲销。他们的 CFO 算过一笔账：每个月产生的舍入差异大约在 200 块钱以内，而系统改造的报价是 12 万。200 块钱一个月，12 万相当于 600 个月即 50 年的差异。结论很清楚：不做改造，用流程消化差异。
这个决策逻辑是完全合理的。我想强调的是，你做不做改造，至少应该知道这个问题存在，并且能量化它。如果你连自己系统里每个月因为舍入误差产生了多少差异都不知道，那才是真正的风险。
我的建议是：先把问题量化，再决定怎么处理。跑一遍诊断三步法，算一个数字出来。如果这个数字在你的业务容忍范围内，那就建一个流程去定期消化它。如果超过了容忍范围，那就根据你的企业体量选择对应方案。
我做了这么多年数据系统诊断，一个越来越深的体会是：企业数字化的水平，往往不体现在用了多先进的系统、接了多少个平台，而是体现在对细节的掌控力上。
克与千克的舍入误差，单笔不过几克、几毛钱，放一个月可能也就几百块。但如果你有 5000 个 SKU、每天 3000 笔交易、5 个仓库，这个误差在一个季度里可能放大到数万元。而它对决策的影响远比账面数字更深远，错误的库存数据会触发错误的采购决策、错误的促销决策、错误的仓间调拨决策。决策依据哪怕偏差 1%，执行结果可能偏差 10%。
这不是一个技术问题。这是你对自己的库存数据到底有多认真。
下一步，如果你读到了这里，我建议你做三件事：
把这三件事做完，你对这个问题的认知就已经超过 90% 的同行了。
我负责公司的进销存系统，经常发现库存数据与实际称重对不上。比如入库1.256千克，系统显示1.3千克，但实际称重又差一点。这到底是哪里出了问题？
我在给一家中型食品企业做系统优化时踩过这个坑。根本原因在于计算机里浮点数（float/double）无法精确表示1/10这样的十进制小数。比如1.256千克在内存里可能是0b1.010000011…的近似，存到数据库时如果字段类型是float，就产生了误差。
更麻烦的是四舍五入规则不一致：采购入库时系统可能用了四舍五入保留3位小数，销售出库时用了向上取整保留2位，同一个物料不同操作导致偏差。
我亲眼见过一个案例：某sku入库1.256kg→系统记录1.26kg（四舍五入），出库0.625kg→系统记录0.63kg（也是四舍五入），但1.26-0.63=0.63，实际还剩0.631kg，每次少0.001kg，一年上千笔交易就少了好几公斤。
我测试了几家主流ERP，发现很多SaaS进销存软件在单位换算时直接用浮点数运算，结果是灾难的。
我们公司有几千个SKU，每个都要多次入库出库，担心微小的四舍五入误差最终导致库存差异几千元。有人经历过这种问题吗？误差大概会放大到什么程度？
我帮一家连锁烘焙店做过数据盘查，他们每批面粉入库时称重记录到0.1kg，出库分装时按重量递减，系统用千克存储并自动四舍五入到0.1kg。我拉了他们半年的数据做了个模拟：一个批次100kg面粉，分100次出库，每次出库0.99~1.01kg不等。
如果每次出库前系统库存四舍五入到0.1kg再减，半年后系统显示库存剩余3.5kg，实际称重只有2.8kg，差了0.7kg。按单价4元/kg，仅这一种原料就损失2.8元。全店50种原料、300个门店，年损失超40万元。这还是保守估计，因为每次四舍五入要么少给客户要么亏自己。
我做过一个对比表（单位：克）：
| 交易次数 | 精确累加 | 四舍五入累加 | 误差 |
|---|---|---|---|
| 100 | 10000.0 | 10007.5 | +7.5 |
| 1000 | 100000.5 | 100121.0 | +20.5 |
| 10000 | 999992.0 | 1000489.0 | +497.0 |
误差随交易量线性增长，远超你想象。
我们软件开发团队在讨论库存系统的重量字段设计，有人说统一用克存储，有人说用千克省空间。哪种方案能彻底避免舍入误差？有没有具体的工程实践指导？
我曾在两个项目里分别用了两种方案，最终推荐：所有重量以“整型克”存储（即用int存克数，不存小数）。原因是：①int没有精度问题，1千克就是1000，永远不会出现1.0000001；②运算速度快，无需浮点指令；③展示时除以1000转换成千克，仅在UI层做四舍五入，不影响底层数据。
相反，用decimal(10,3)存千克虽然比float好，但仍有小数运算风险，而且数据库占用空间更大（decimal比int多2-4字节）。我测试过：对100万条记录按克累加，int方式总误差为0；
decimal(10,3)方式如果频繁除法/乘法，会有0.001级的累积误差（因为decimal也不是所有除法都精确）。
一张对比表：
| 存储方案 | 类型 | 存储空间 | 100万次运算误差 | 推荐场景 |
|---|---|---|---|---|
| 整型克 | INT | 4字节 | 0 | 任何需要高精度的库存系统 |
| 千克-小数 | DECIMAL(10,3) | 5-9字节 | ≤0.001千克 | 报表展示层 |
| 千克-浮点 | FLOAT | 4字节 | 可达0.5千克 | 极不推荐 |
实践建议：设计库表时重量字段用weight_g INT UNSIGNED，存克数；
前端录入时直接输克或千克自动转；出库时也按克减。这样彻底根除换算误差。
我不是技术人员，但作为运营总监，总感觉库存数据不对劲。有什么简单的自查方法能判断系统是否存在克与千克换算的bug？最好不用看代码。
我为一家连锁药店做库存审计时总结了一套三步自查法，不需要懂代码： 第一步：挑一批有精确小数记录的商品（比如0.256kg），在系统中找到最近10次入库和10次出库的明细，用Excel手动计算每次变动后的理论库存（精确到0.001kg），再与系统显示的库存对比。
如果每次差异都在0.001kg以上，说明换算存在误差。第二步：检查系统“取整规则”。批量导出一些商品的历史重量记录，看系统中记录的值是否总是xxx.x或xxx.xx（即固定小数位数）。如果每次都是四舍五入到0.1kg或0.01kg，说明系统在存盘点时已经失准。
我遇到的一个真实案例：某品牌奶茶原料的库存，系统里全是0.0、0.5、1.0这种整数或半整数，实际用精准秤称重却是0.237、0.486、1.013，系统吞掉了小数位。第三步：做一次全品类盘点，称重后与系统存量对比，记录误差绝对值占总存量的比例。如果超过1%，基本可判定存在单位换算问题。
我查过的那家药店，误差率达到了3.2%，多数是因为入库时自动把0.253kg截断成0.2kg（系统用了向下取整）。按这个方法，一个月内就能定位问题，然后要求IT整改存储方案。
读者评论
作为负责过ERP实施的技术人员，这篇文章彻底点醒了我。以前遇到库存误差，我们第一反应就是查数据库字段精度、改decimal位数，但问题根本不在那儿。作者说的‘算太早’太对了，我们在入库确认那一步就四舍五入，后面再怎么修存储都没用。现在复盘，01号客户那次OEM食品库存差异，就是蜂蜜案例的现实版。
财务角度看这篇太戳心了。我们公司每个月盘亏几万块，IT和仓库互相甩锅，最后发现就是克千克换算埋下的坑。特别是那个‘幽灵库存’描述，系统显示0.05千克，实际上库房早空了，库龄报表上挂着几十个SKU永远清不掉，财务月结时处理这些差异的隐性成本远超预期。
作为一个每天和称重打交道的仓库主管，我太有共鸣了。入库界面只给两位小数，0.375公斤根本输不进去，只能硬着头皮打成0.38。供应商送货单上是精确到克，系统录入时却自动舍入，月结盘亏永远对不上。文章提的‘入库统一用克’方案确实好，但供应商配合难度大，期待有更落地的系统方案。