Counter减法默认保留负值，需手动实现零截断：遍历左右键并集，对每键取max(0, left[k]-right.get(k,0))构造新Counter。
collections.Counter 减法默认允许负数，必须手动过滤
Counter 的 - 运算符（即 __sub__）本质是逐键相减，结果中键值为负时**不会自动丢弃或截断为 0**。这和直觉中的“集合差”或“安全减法”不一致。例如：Counter({'a': 2, 'b': 1}) - Counter({'a': 3, 'b': 0}) 得到 Counter({'a': -1, 'b': 1})，其中 'a' 的 -1 是合法但通常无意义的。
用 items() + 字典推导实现零截断减法
最直接可控的方式是遍历左操作数的全部键，对每个键计算 max(0, left[key] - right.get(key, 0))，再构造新 Counter：
from collections import Counterdef safe_sub(left: Counter, right: Counter) -> Counter: return Counter({ k: max(0, left[k] - right.get(k, 0)) for k in left.keys() | right.keys() })
示例
a = Counter({'x': 5, 'y': 2}) b = Counter({'x': 7, 'z': 1}) result = safe_sub(a, b) # Counter({'y': 2})
- 必须显式用
left.keys() | right.keys()覆盖所有可能涉及的键，否则会漏掉right中有而left中没有的键（它们在结果中应为 0，且不应出现） -
max(0, ...)确保不出现负值，也避免了Counter构造时隐式跳过 0 值（Counter本身会忽略 0 值，但这里我们主动控制逻辑） - 不依赖
Counter.subtract()，因为它就地修改且仍允许负值
用 elements() + 手动计数不如字典推导简洁
有人尝试用 list(a.elements()) 展开再移除，比如转成列表、逐个 remove()，但这在多键、大数量时性能差、不可靠（remove() 只删第一个匹配），且无法处理键值为 0 或负的中间状态。不推荐。
-
elements()返回迭代器，重复键按频次展开，内存开销与总元素数成正比，不是频次字典的紧凑表示 - 对
Counter({'a': 1000}) - Counter({'a': 999})，展开成列表再删 999 次'a'是低效的 - 无法原子化处理多个键之间的依赖（如“减完 a 再减 b”，但实际应并行按键独立计算）
注意：Counter.update() 和 += 不解决负数问题
update() 是加法，subtract() 是减法但不截断——它和 -= 一样，会保留负值。例如：c = Counter(['a']); c.subtract(['a', 'a']); print(c) 输出 Counter({'a': -1})。所以不能靠它“模拟安全减法”。
-
subtract()设计目标就是支持负频次（用于某些统计差分场景），不是 bug - 若业务逻辑要求“减不够就归零”，就必须在外层封装逻辑，不能依赖
Counter内置行为 - 别试图用
+=配合负Counter来绕过，因为Counter({k: -v})构造后，+=仍是带符号加法
实际使用时，最容易被忽略的是键空间范围——只遍历 left.keys() 会漏掉 right 中存在但 left 中为 0 的键，而这些键在“安全减法”结果中本就不该出现；但若误用了 right.keys() 单独参与计算，又可能引入不该有的键。统一用 left.keys() | right.keys() 是唯一稳妥覆盖。
