Python Counter 减法把负数丢了：subtract 与多重集合运算的边界

盘点差额里明明有短缺，做完Counter减法却只剩下多余项。不是计数器不会存负数，而是多重集合运算会过滤非正结果；如果需要完整有符号差额，应选择另一份操作合同。

Counter既可以保存一般计数，又提供面向正计数多重集合的运算。两套能力放在同一类型上，写法只差一个subtract，就可能让对账信息少一半。

以下使用Python 3.12。例子中的数量是小整数，比较一份预期颜色数量与一份实际数量，不连接库存系统，也不声称处理了并发扣减。

让正差、负差与抵消分别可见

保存counter_balance.py执行：

from collections import Counter

expected = Counter({'red': 5, 'blue': 2})
actual = Counter({'red': 3, 'blue': 4, 'green': 1})

surplus = actual - expected
shortage = expected - actual
signed = actual.copy()
result = signed.subtract(expected)
print('surplus:', dict(surplus))
print('shortage:', dict(shortage))
print('signed actual - expected:', dict(signed))
print('subtract return:', result)
assert surplus == Counter({'blue': 2, 'green': 1})
assert shortage == Counter({'red': 2})
assert dict(signed) == {'red': -2, 'blue': 2, 'green': 1}
assert result is None
assert actual['red'] == 3

print('positive side:', dict(+signed))
print('negative magnitude:', dict(-signed))
print('signed total:', signed.total())
assert signed.total() == 1
assert sum(abs(count) for count in signed.values()) == 5

zero = Counter({'a': 0})
print('zero mapping len:', len(zero), 'truth:', bool(zero))
print('missing read:', zero['missing'], 'inserted:', 'missing' in zero)
assert zero['missing'] == 0 and 'missing' not in zero
assert Counter(a=1) == Counter(a=1, b=0)
print('zero equality:', Counter(a=1) == Counter(a=1, b=0))

accumulated = Counter({'a': 2})
accumulated.update({'a': 3})
print('update adds:', accumulated['a'])
assert accumulated['a'] == 5
with_zero = Counter({'red': -2, 'blue': 0, 'green': 1})
without_zero = Counter({key: count for key, count in with_zero.items() if count != 0})
assert dict(without_zero) == {'red': -2, 'green': 1}
print('remove only zero:', dict(without_zero))

actual-expected得到多余的蓝色2、绿色1，红色-2没有进入结果；反向减法得到短缺红色2。subtract则原地保留红色-2、蓝色2、绿色1，并返回None，而不是返回那份新计数器。

这两种结果没有谁普遍更正确。发放“还缺哪些物品”清单，可以取expected-actual；保存完整盘点差额，则需要有符号结果。不能在已经过滤负数的结果上继续计算，再希望后来知道哪些项目短缺。

两种减法还改变了对象生命周期

actual - expected生成新的Counter，原来的actual不变。signed.subtract(expected)修改接收者，所以程序先copy，避免把输入基线直接改掉。

如果同一份Counter还被其他代码引用，原地subtract会影响那些观察者。函数名相近不能代替所有权说明；对账输入应保留为原始快照，结果另存，后续才有条件解释计算依据。

update也与普通dict.update不同。Counter.update把计数相加，a原来2、再update3，结果是5，而不是3。想直接设值可以明确赋值，想累计就使用相应方法，别在切换容器类型时保留旧假设。

正侧与负侧的投影，会故意丢信息

一元加号 +signed只保留正计数，一元减号 -signed将负侧取正幅度。它们适合生成多余与短缺的独立清单，却不该当作无损清理操作。

常见写法 counter += Counter()也会按多重集合规则去掉非正计数。如果这份Counter表示债务、净变化或库存差额，负数本来就有业务含义，这样的“标准化”会抹掉证据。

只想删除零项时，可以像最后一段一样按count不等于0构建结果，负数继续保留。是否删零也应由输出格式决定：某个键明确存在且为0，与从未登记，在审计模型中可能仍然需要区分。

Counter并不替业务定义键身份。颜色字符串是否大小写归一、供应商编码是否裁剪空白，都应在计数前确定。两个系统用不同规范化规则生成Counter，即使最后减法完全正确，差额也未必代表真实短缺。

total 为零，也不证明所有项目都相等

示例的有符号total为1，而绝对差额合计为5。正负可以抵消，净数反映总体增减，不反映不同键分别发生了多少偏差。

同理，红色少2、蓝色多2，total可以为0，逐项仍不一致。对账应检查每个键的差额，或明确定义允许跨键抵消的业务规则，不能只比较两边总量。

若要报告差异项数量，也不要把sum(abs(count))当成键数。前者是单位数量，后者可以用非零键的个数；它们与原始记录条数又是不同口径。报告中写清单位，能避免一个“差异5”被读成五个文件或五种颜色。

零计数存在，缺失读取却不会插入

Counter读取缺失键返回0，示例同时确认missing仍不在容器中。已有a=0则会占一个键，len为1，bool也为True。不能用if counter直接判断“还有没有正数量”。

Python从3.10起，Counter相等比较把缺失项当0处理，因此Counter(a=1)与Counter(a=1,b=0)可以相等，虽然它们显式保存的键集合不同。本文按3.12运行；需要支持更老版本时，不应把这条结果当作历来不变。

若要求导出完全相同的显式字段，应比较规范化后的字典或明确字段模型，而不是仅用Counter相等作为序列化一致性证据。数学计数相等与结构表示相等回答不同问题。

most_common同样需要按用途解释，它排序现有计数，不意味着先把非正项过滤。对有符号差额直接取前几项，得到的是数值最大的键，不一定是绝对偏差最大的键；红色负二可能被蓝色正一排在后面。要按偏差幅度定位问题，应明确按绝对值排序，并保留原符号用于解释方向。

elements则面向按计数重复展开的元素，零和负数不会产生相应元素；它不是保存有符号差额的编码。对大计数再转成列表，还会把紧凑计数展开成大量对象引用。报表只需数量时保留键值结构，不必为了遍历方便恢复每一件虚拟物品。

先保存完整差额，再选择展示方式

一种较清楚的流程是保留expected、actual与有符号signed，然后从signed派生正侧、负侧和汇总指标。展示需要可以变化，底层证据仍完整。

这份示例只在内存里处理已完成的两份快照，不提供持久事务或并发一致性。真实库存扣减还需要存储层的条件写入和冲突处理，Counter能表示负数不代表业务可以无条件把它写成实际库存。

重新核对原问题时，先检查负数是输入里没有，还是在二元减法、一元清理或中间赋值时被丢掉。对这几处分别断言，通常比在最终报表里补一套猜测短缺的逻辑更可靠。