按频次降序排应调用 most_common() 方法，它返回 (key, count) 元组列表，全量排序用 most_common()，TopN 用 most_common(k)，比 sorted(counter.items(), key=lambda x: x[1], reverse=True) 更高效且语义明确。
Counter 统计后怎么按频次降序排？
默认的 Counter 实例是无序的，直接遍历或转 dict 不保证高频在前。要排序得手动调用 most_common() —— 它返回的是 list，每个元素是 (key, count) 元组。
常见错误：写成 sorted(counter.items(), key=lambda x: x[1], reverse=True)，虽然能跑通，但多此一举，most_common() 就是为此设计的，且内部优化过。
-
counter.most_common()返回全部，按频次从高到低 -
counter.most_common(5)只取前 5 个，适合 TopN 场景 - 如果频次相同，顺序取决于插入顺序（Python 3.7+ 保持 dict 插入序）
- 注意：
most_common()返回的是新列表，不改变原Counter对象
字符串/列表直接传给 Counter 会出什么问题？
Counter 构造时接收可迭代对象，但对字符串和列表的“拆解粒度”不同：字符串会被逐字符计数，列表则按元素计数。这点极易误判结果。
比如 Counter("abab") 得到 {'a': 2, 'b': 2}；而 Counter(["ab", "ab"]) 得到 {"ab": 2}。若本意是统计单词却传了空格未分割的长字符串，就会全按字统计，结果完全不对。
立即学习“Python免费学习笔记（深入）”；
- 统计单词：先用
.split()或正则切分，再传给Counter - 统计行、文件每行内容：确保输入是
list，不是把整个文件字符串直接丢进去 - 统计字符频率（如密码分析）：字符串可直接传，但需明确这是字符级而非词级
Counter 和 dict 混用时哪些操作会报错？
Counter 是 dict 子类，多数操作兼容，但两个关键行为差异常导致隐性 bug：
-
counter["missing_key"]默认返回0，而普通dict报KeyError；若后续逻辑依赖 KeyError 触发 fallback，这里就静默失败 -
counter.update()对不存在的 key 会加 0（即无副作用），但对已存在 key 是累加；而dict.update()是覆盖。混用时容易误以为在“合并”，实际是“频次叠加” -
counter.elements()返回迭代器，生成所有重复元素（如Counter(a=2)→['a', 'a']），普通dict没这方法 - 做集合运算（
+ - & |）时，Counter有定义，dict没有，直接用会报TypeError
大数据量下 Counter 的性能瓶颈在哪？
Counter 本质是哈希表，单次插入/查询是 O(1)，但构造时遍历整个输入是 O(n)。真正拖慢的往往是「非必要重复构造」和「误用 most_common()」。
- 别在循环里反复写
Counter(data)，尤其 data 是大列表——应提前构造一次复用 -
most_common(k)在 k 远小于总类别数时很快，但most_common()（无参数）需对全部键排序，O(m log m)，m 是不同元素个数；若只取 Top10，别调用全量版 - 纯计数不需排序？直接遍历
counter.values()或用sum(counter.values())算总数，比most_common()轻量得多 - 内存上，
Counter会为每个唯一值存一个键值对，极端稀疏场景（如日志 ID 计数）要考虑是否该用更紧凑结构（如数据库或专用流算法）
Counter 好用，但它的“默认返回 0”和“自动排序接口”这两个特性，恰恰是最容易让人忽略边界条件的地方。
