Python字符统计全解析：从Counter到Unicode与大文件流式优化

做 Python 字符统计这件事，我原本以为是最没技术含量的活——直到上周有位做数据清洗的朋友发来一段脚本，说同一个文本文件，他用程序数出 12874 个字符，另一位同事用办公软件的字数面板看到的是 12093，两个人对着屏幕核对了半天也没找出差在哪。这类问题我自己也踩过不止一次：字符统计看着只是Counter(text)一行代码的事，真扔到生产环境里，编码、字素簇、全角半角、大文件内存、统计口径，随便哪个环节都能让你对数对到怀疑人生。

这篇就把我这些年做 Python 字符统计的完整思路摊开讲：从最朴素的循环累加，到Counter的底层实现细节，再到几十 MB 甚至几个 GB 文本的流式处理与并行加速，最后附上几份可以直接抄走改改就用的模板。不管你是刚学完 dict 想练手的新手，还是已经在写日志分析、文本清洗、密码强度校验这类功能的老手，应该都能从里面找到点能省时间的东西。文中所有例子都是我自己在项目里跑过的简化版，参数和结论可以直接参考，但具体阈值还是得按你自己的数据分布调。

1. 先把需求拆开：字符统计到底在统计什么

动手写代码之前不把这层想清楚，后面返工的概率极高。我见过太多人上来就写len(text)，结果需求方要的是"可见字符数"，或者要排除标点和空白，或者要按"用户看到的一个字"来算。这三种口径在纯英文文本里差别不大，一旦混进中文、日文、emoji 或者带变音符号的拉丁字母，结果能差出百分之几甚至十几。

1.1 三个层面的"字符"：码点、字素簇与字节

Python 3 的str内部存的是 Unicode 码点序列，len("中文")返回 2，len("ab")也是 2，看起来挺直觉。问题出在组合字符上：比如"é"这个字符，它既可以是单个码点 U+00E9，也可以写成"e"加一个组合用重音符 U+0301，后者在 Python 里len()会返回 2。你从不同来源（某些 macOS 文件系统、部分输入法、网页复制粘贴）拿到的同一段文字，底层码点序列可能完全不同，但屏幕显示一模一样。

更极端的是 emoji。一个家庭 emoji 在底层可能是好几个码点用零宽连接符串起来的，len()出来是 5 到 7 不等，而用户眼里它就是"一个表情"。所以如果你的统计口径是"用户感知到的字符数"，那就得按字素簇（grapheme cluster）来切，标准做法是用regex模块的\X模式，或者引入专门的字素切分库，re标准库做不到这一点。

至于字节层面，那是另一回事了。UTF-8 编码下一个汉字占 3 字节，一个 emoji 占 4 字节，len(text.encode('utf-8'))和len(text)完全不是一回事。做数据库字段长度校验、做网络传输体积估算的时候，你要的是字节数，千万不能拿len()交差。

提示：先问清楚统计口径再写代码。字符数、字素数、字节数、可见字符数，四个概念在中文和 emoji 场景下差异非常明显。

1.2 需求分层决定方案选型

我把常见的字符统计需求分成四层，每一层对应的最优方案完全不同，选错了要么慢得离谱，要么代码复杂到没人愿意维护。

第一层最简单，但最容易踩坑的是"清洗之后再计数"这个动作本身——正则写错一个字符类，结果就全偏了。第二层是绝大多数人停留的地方，Counter确实好用，但它有几个反直觉的行为后面会细说。第三层和第四层才是真正体现功力的地方，也是我下面重点展开的部分。

我觉得判断一个人是不是真的写过文本处理代码，看他会不会在统计之前先问一句"这个文本的编码和规范化形式确认过了吗"，基本就八九不离十了。

2. 从零到一：基础实现的四种写法与取舍

同一个需求，Python 里至少有四种写法，性能能差出几倍到几十倍，代码可读性也各有取舍。我把它们逐一拆开讲，重点不是告诉你哪个最快，而是让你明白每个方案快在哪里、慢在哪里，遇到具体场景能自己判断。

2.1 手写字典累加：最笨但最可控

最原始的写法就是一个 for 循环加dict.get：

def count_chars_basic(text): result = {} for ch in text: result[ch] = result.get(ch, 0) + 1 return result

这段代码慢的原因很明确：每一轮循环都要调用一次dict.get，一次加法，一次dict.__setitem__，全是 Python 层的字节码开销。十万字符的文本，这个写法大概要跑十几毫秒。但它有个巨大优势——逻辑完全透明，你可以在循环里插任何判断，比如跳过标点、合并大小写、按字符类别分流统计。

我实际项目里保留这种写法的场景只有一个：统计逻辑复杂到Counter表达不了。比如要同时统计"每个字符的出现次数"和"每个字符首次出现的位置"，或者要按段落分别统计再汇总，这时候手写循环反而更清爽。

2.2 str.count 与 set 组合：短文本的偷懒写法

很多教程会推荐这个写法：

def count_chars_str_count(text): return {ch: text.count(ch) for ch in set(text)}

看起来很优雅，set去重拿到所有不重复字符，然后对每个字符调一次str.count。这段代码在短文本上跑得飞快，因为str.count是 C 层实现的，有专门的快速搜索算法。但它有个致命的复杂度问题：时间复杂度是 O(n·k)，n 是文本长度，k 是不重复字符数。英文文本 k 大约 60 到 80，中文长文本 k 可能上千，这时候它比手写循环还慢好几倍。

我做过一组实测，用的是 50 万字符的中文语料，不重复汉字大约 3000 个：

str.count这写法唯一的适用场景是：文本很短（几百字符以内），而且你只关心少数几个特定字符的出现次数，比如统计一段话里有几个感叹号、几个问号。这种情况直接写text.count('!')就完事，连 set 都不需要。

2.3 collections.Counter：标准答案与它的隐藏细节

Counter是绝大多数场景的正确答案，但很多人只是把它当黑盒用，不知道它为什么快。CPython 里Counter.update对可迭代对象做了特殊处理：如果传入的是字符串这类可迭代对象，它会走一个叫_count_elements的 C 函数，直接在 C 层完成"遍历 + 累加"，完全绕开 Python 的循环开销。这就是它比手写循环快将近十倍的根本原因。

不过Counter有几个行为值得单独拎出来说，我见过不少人在这里翻车：

• Counter是dict的子类，访问不存在的键返回 0 而不是抛KeyError，这个特性很方便，但也意味着你没法用in来判断"这个字符出现过没有"——'x' in counter永远是 False，除非你真的存过这个键。
• most_common()不带参数时返回全部，内部走的是排序；带参数most_common(10)时走的是heapq.nlargest，数据量大时后者明显快。但要注意，计数相同的字符之间的相对顺序，取决于底层 dict 的插入顺序，Python 3.7 之后是插入有序的，但这不是"稳定排序"的语义，别依赖它做业务判断。
• Counter支持加减和交并运算，两个 Counter 相减会丢弃零值和负值，做字符集差集的时候很方便，但做"变化量分析"的时候要小心。

from collections import Counter text = "数据清洗 Data Cleaning 2024" c = Counter(text) print(c.most_common(3)) # [(' ', 3), ('a', 2), ('数', 1)]

上面这个小例子能看出，空格往往是大文本里出现频率最高的"字符"，如果你做字频分析之前不清洗空白，排行榜前几名全是空格和换行符，非常影响观感。

2.4 四种写法怎么选：一张决策表

我把选型逻辑整理成一张表，遇到新需求直接对号入座：

有一点我想强调：不要过早优化。如果你处理的是几 KB 的用户输入，Counter和手写循环的差别在微秒级，用户根本感知不到，这时候可读性最重要。只有当文本量上到几十万字符、或者每秒要处理成百上千个请求时，性能差异才会变成真问题。

3. 统计前的清洗：比统计本身更容易翻车的环节

我经手的字符统计 bug 里，至少七成不是出在计数逻辑上，而是出在清洗上。清洗做错了一个环节，后面统计得再快再准也没意义。这一节把几个高频的清洗陷阱拆开讲。

3.1 大小写归一与 Unicode 规范化

做英文词频统计，第一步通常是转小写，但lower()并不像你想的那么安全。有些字符转小写之后长度会变，比如土耳其语里大写 I 带点的那种写法，lower()之后变成两个字符；德语里的ß转大写是SS，长度也变了。如果你先用lower()再按位置对齐做别的处理，很可能会错位。

做不区分大小写的比较，更稳妥的选择是casefold()，它比lower()更激进，会做更彻底的大小写折叠，适合用于"判断两个字符串是否等价"这类场景。但如果你的目标是保留原文结构只做统计归并，那就得接受折叠后长度变化的事实，提前做好心理准备。

Unicode 规范化是另一个必须提的点。同一段文字可能有四种规范化形式：NFC、NFD、NFKC、NFKD。前两个是组合还是分解，后两个额外做兼容性转换。从不同系统、不同软件里拿到的文本，规范化形式很可能不一致，你统计"é"的频次时，一部分是单码点，一部分是双码点，结果被拆成两半。

import unicodedata from collections import Counter a = "café" # e + 组合重音符，长度 5 b = unicodedata.normalize("NFC", a) # 合并成单码点，长度 4 print(len(a), len(b)) # 5 4 print(Counter(a).most_common(2)) print(Counter(b).most_common(2))

上面这段跑一遍你就能直观看到差异。我的建议是：在统计入口处统一做一次 NFC 规范化，成本很低，能消灭掉一大类莫名其妙的"结果对不上"问题。除非你的业务明确需要保留原始码点形式，那就另说。

注意：NFKC会做兼容性转换，把全角字母转半角、把①转成1、把罗马数字转成普通字母。做展示类处理很合适，做"忠实统计"就不合适了，因为它改变了字符本身。

3.2 标点、空白与全角半角的处理

中文文本里全角标点和半角标点混用是常态，顿号、引号、括号尤其混乱。统计之前不做归一，你会发现同一个视觉字符在结果里出现两次，一次全角一次半角。同理，中文全角空格 U+3000 和普通空格 U+0020 在视觉上几乎一样，在统计里是两个完全不同的键。

我的处理习惯是分两步走：先做NFKC把全角字母数字符号转半角，再单独处理那些不想被兼容转换的字符。但NFKC有一个副作用前面提到了，它会把一些特殊符号也转掉，所以如果你的文本里有数学符号、单位符号，先用小样本验证一遍转换结果再全量跑。

清洗标点最常见的手段是正则：

import re def strip_punct(text): # 保留字母、数字、空白，其余删除 return re.sub(r"[^\w\s]", "", text)

这里有个特别容易踩的坑：Python 3 的\w默认是 Unicode 语义，它匹配所有 Unicode 单词字符，包括汉字、日文假名、韩文。很多人以为\w只匹配[a-zA-Z0-9_]，写出re.sub(r"[^\w\s]", "", 中文文本)之后发现汉字全保留了，还以为代码出错。反过来，如果你真的只想保留英文字母数字，得显式写[^a-zA-Z0-9\s]或者加re.ASCII标志。

清洗的另一个高频需求是删空白。str.split()不带参数会按任意空白切分并丢弃空串，" ".join(text.split())是压缩多余空白的经典写法，比正则快不少。删全部空白就直接re.sub(r"\s+", "", text)或者用translate配合str.maketrans建表，后者在需要删多个不同字符时更快。

3.3 中文、日文与 emoji 的特殊对待

中文场景下最常见的需求是"统计每个汉字出现多少次"，但直接Counter会把标点、数字、字母全算进去。想只要汉字，可以用 Unicode 区间判断：

def is_cjk(ch): code = ord(ch) return 0x4E00 <= code <= 0x9FFF or 0x3400 <= code <= 0x4DBF

基本汉字区是 U+4E00 到 U+9FFF，扩展 A 区是 U+3400 起。实际语料里偶尔还有扩展 B 区之后的生僻字，在 U+20000 以上，Python 3 能正常处理，但如果你的下游系统是某些老版本数据库，可能会出问题，这一点要提前确认。

emoji 的处理更麻烦一些。前面说过 emoji 可能是多码点组合，如果按码点统计，一个家庭 emoji 会被拆成好几个键，most_common出来的结果里全是零散的连接符和肤色修饰符。解决办法有两个：一是接受码点维度统计，在展示时做映射；二是引入字素切分，按视觉字符统计。

import regex # 第三方库，标准库 re 不支持 \X def count_graphemes(text): from collections import Counter return Counter(regex.findall(r"\X", text))

这个写法对中文和普通符号没有影响（一个汉字就是一个字素），但能把组合 emoji 正确归并。如果你的产品里有用户昵称、评论内容需要统计长度或频次，我强烈建议用字素维度，否则用户会觉得"我明明只打了五个字，你怎么说超长了"。

4. 高阶优化：从能跑到跑得快的几道坎

前面讲的都是"正确性"层面的东西，这一节换到"性能"层面。数据量一旦上到几十 MB 以上，原始写法会撞上两个墙：内存占用和运行时间。我按优化收益从大到小排列，你可以按需取用。

4.1 大文件分块读取与流式统计

open(path).read()把整个文件读进内存，文件 2 GB 的时候你的进程可能直接被系统干掉。正确做法是分块流式处理，每读一块就更新一次累加器：

from collections import Counter def count_file(path, chunk_size=4 * 1024 * 1024): total = Counter() with open(path, "r", encoding="utf-8", errors="replace") as f: while True: chunk = f.read(chunk_size) if not chunk: break total.update(chunk) return total

这里chunk_size的选择有点讲究。太小了系统调用次数多，IO 开销占比高；太大了单次内存占用高，对并发不友好。我实测下来 1 MB 到 8 MB 之间差别不大，4 MB 是个比较稳妥的默认值，大致对应大多数系统的预读块大小量级。真正影响性能的反而是磁盘本身的顺序读速度，SSD 上这个循环跑到几百 MB/s 很正常，机械盘就老老实实接受现实。

用文本模式读有个隐藏的好处：Python 会在TextIOWrapper层处理 UTF-8 多字节字符的跨块边界问题，你不需要担心一个汉字被切成两半。但代价是解码开销，纯 ASCII 大文件用二进制模式读再自己解码会更快一些。如果确定文件是单字节编码（比如 ASCII 日志），直接open(path, "rb")然后用Counter统计bytes对象，速度还能再提一截，因为bytes的遍历返回整数，Counter对它的处理路径更短。

提示：用二进制模式读时，如果文本是多字节编码，务必处理块边界的字符截断，否则统计结果里会冒出一堆乱码键。稳妥做法是用codecs.getincrementaldecoder做增量解码。

4.2 减少 Python 层循环的几种手段

性能优化的核心原则就一句：把循环从 Python 层推到 C 层。具体有几种常见做法，收益递减排列如下。

第一种，用Counter.update而不是自己累加，前面已经说过，收益最大，通常有 5 到 10 倍。第二种，用str.translate批量替换或删除字符。translate接受一张映射表，一次性扫完整个字符串，比逐字符判断快得多：

def normalize_text(text): table = str.maketrans({ "\u3000": " ", # 全角空格 "\u00a0": " ", # 不间断空格 "\r\n": "\n", "\r": "\n", }) return text.translate(table)

第三种，用str.count统计少数固定字符。如果业务只关心几个特定字符（比如密码强度校验要看有没有大小写字母和数字），完全没必要统计全量分布，几次str.count加起来可能比Counter还快。第四种，把循环里的属性访问提到外面，比如update = counter.update这样绑定一次，在循环次数上百万的时候能省下可观的字节码开销。

4.3 内存受限场景的位图与数组方案

Counter的每个条目本质是一个 dict entry，开销不小：一个键对象、一个整数值对象、哈希表槽位，加起来几十到上百字节。统计全量汉字（几千个键）无所谓，但如果你的场景是"统计所有可能的 Unicode 码点"，那就是一百多万个键，内存直接起飞。

这种场景的解法是用定长数组。如果只统计 ASCII 范围内的字符，256 个槽位就够了：

import array def count_ascii_fast(data: bytes): counts = array.array("I", [0]) * 256 for b in data: counts[b] += 1 return counts

array("I")每个元素 4 字节，总共 1 KB，完全在缓存里，速度快到几乎不受内存带宽限制。缺点是这个循环还是 Python 层的，好在 256 分支的简单累加，CPython 每秒钟也能处理几百万字节。

如果连 Python 循环都想省掉，可以考虑用bytes.count对每个可能的字节值各调一次——256 次 C 层扫描。听起来很傻，但实际测下来在几十 KB 以上的数据上反而更快，因为每次扫描都是高度优化的memchr路径。这个技巧我在处理大型二进制日志的时候用过，效果比想象中好。当然如果数据量只有几 KB，256 次调用的固定开销就占大头了，得自己掂量。

4.4 并行化的边界：什么时候多进程才有意义

很多人一想到"大文件处理"就想上多进程。我的经验是：单进程跑到 IO 瓶颈之前，别碰并行。字符统计是纯 CPU 密集型任务，multiprocessing确实能吃到多核，但前提是分块策略要对，否则光是进程间传输数据的开销就把收益吃干净了。

分块并行的关键是"按字节偏移切，切完对齐到行边界"。具体做法：把文件按字节切成 N 段，每个进程 seek 到自己的起点，然后向后找到第一个换行符作为实际起点，再向后找到下一个换行符作为终点。这样每个进程处理的都是完整行，不会把一个汉字或一行日志劈开。

from multiprocessing import Pool def count_segment(args): path, start, end = args from collections import Counter c = Counter() with open(path, "rb") as f: f.seek(start) if start != 0: f.readline() # 丢弃不完整的首行 pos = f.tell() while pos < end: line = f.readline() if not line: break pos = f.tell() c.update(line) return c

子进程返回的都是Counter，主进程再做一次合并。合并本身是 O(k)，k 是不重复字符数，相对于统计开销可以忽略。需要注意Counter要能跨进程 pickle，这个它支持，但如果你自己封装了类，记得检查一下。

什么时候不值得并行？文件小于 50 MB、或者磁盘是机械盘、或者你在容器里被限制了单核，这三种情况下并行往往是负收益。我自己有个简单判断：先跑单进程，用time.perf_counter测出纯计算耗时，如果计算耗时占比不到总耗时的 30%，说明瓶颈在 IO，加进程没用。

5. 典型场景实战：三个可以直接抄的模板

理论讲完，来点能直接用的。下面三个模板都是我从实际项目里抽出来的简化版，参数按需调整。

5.1 中文文本字频统计与词云前置处理

做词云之前通常要先统计字频，但直接Counter出来全是空格和标点，得先清洗。这套流程我用了很多次，稳定性不错：

import re import unicodedata from collections import Counter def cjk_char_freq(text, top_n=50): text = unicodedata.normalize("NFC", text) text = text.lower() chars = [ch for ch in text if "\u4e00" <= ch <= "\u9fff"] counter = Counter(chars) return counter.most_common(top_n)

几个细节：规范化放在最前面，因为后面的区间判断依赖码点形式；lower()对汉字没影响但能统一混入的英文；列表推导里做区间过滤比正则快，因为不需要编译正则对象。如果语料是几十 MB 的，把chars换成生成器传给Counter，内存能省一半——Counter接受任何可迭代对象，不需要先物化成列表。

对于繁体中文或者夹杂日文的语料，区间判断要放宽到 U+3400 到 U+9FFF 再加上 U+3040 到 U+30FF 的假名区。我一般会先跑一个"字符分布探查"脚本，看看未识别字符都长什么样，再决定要不要扩区间，这比拍脑袋写范围靠谱。

5.2 日志字符分布分析与异常检测

这个用法有点偏门但很实用。正常日志的字符分布是相对稳定的，一旦某个服务开始输出异常堆栈或者二进制垃圾，字符分布会明显偏移。用字符分布做粗粒度异常检测，成本极低：

def char_profile(line): c = Counter(line) total = sum(c.values()) or 1 return {ch: n / total for ch, n in c.items()} def is_suspicious(line, baseline, threshold=0.3): prof = char_profile(line) diff = sum(abs(prof.get(ch, 0) - baseline.get(ch, 0)) for ch in set(prof) | set(baseline)) return diff > threshold

基线可以从正常日志里采样几百行平均得到。阈值 0.3 是我在几套系统上调出来的经验值，你们的日志格式不同，得重新标定。这套方法的优势是不需要任何模型、不需要训练，几行代码就能上线，缺点是对短行不敏感——十几个字符的行，分布波动天然就大，容易误报，所以通常配合最小行长度过滤一起用。

5.3 文本相似度计算中的字符向量

做去重或者近似匹配时，字符级 n-gram 向量是个轻量方案。比起词向量，它不需要分词，对中文尤其友好：

def char_ngram_vector(text, n=2): text = re.sub(r"\s+", "", text) grams = [text[i:i+n] for i in range(len(text) - n + 1)] return Counter(grams) def cosine(a, b): common = set(a) & set(b) num = sum(a[g] * b[g] for g in common) den = (sum(v*v for v in a.values()) ** 0.5) * (sum(v*v for v in b.values()) ** 0.5) return num / den if den else 0.0

这里n=2是中文场景的常见选择，双字组合既能捕捉足够信息又不至于维度爆炸。英文场景一般用n=3。注意Counter的键是 n-gram 字符串，短文本上维度可控，长文本建议先做一轮低频过滤，把只出现一次的 gram 扔掉，能显著减少内存和计算量。

注意：这套余弦计算在长文本上会很慢，因为要遍历所有公共 gram。如果文本上千字，先用Counter的&运算取交集再算，或者上sklearn的稀疏矩阵实现，别自己硬写。

6. 常见问题与排查技巧实录

这一节是我这些年踩过的坑的汇总，按问题类型整理，遇到对不上的情况可以直接查表。

6.1 编码相关的坑

统计结果里出现莫名其妙的单字符键：八成是编码问题。文件本身是 GBK 但用 UTF-8 打开，或者反过来，会产生一堆替换字符或者乱码。排查方法很简单，读前 1024 字节打印出来看，或者用chardet这类库做个初步判断（准确性一般，只作参考）。

开头多出一个不可见字符：BOM 头 U+FEFF。Windows 下保存的 UTF-8 文件经常带 BOM，open(encoding="utf-8")不会自动去掉，会把它当成第一个字符统计进去。解决办法是用encoding="utf-8-sig"，Python 会自动剥掉。

同一份文本两次统计结果不一致：检查一下是不是中间经过了某个编辑器另存，或者经过了网络传输。我曾经遇到过一次，中间某环节把 LF 转成了 CRLF，\r直接多出一倍的量，most_common排行榜都变了。

6.2 统计结果对不上的排查

和办公软件的字数统计不一致：最常见的原因是统计口径不同。办公软件通常统计"字符数（不计空格）"和"字符数（计空格）"两个值，还可能有"字数"这个按词计算的指标。中文里一个汉字算一个字，英文里一个单词算一个字，跟你按码点统计完全是两套逻辑。先把口径对齐，别急着改代码。

自己两次跑结果不一样：检查是不是用了set做中间容器。set的迭代顺序在不同进程间可能不同（哈希随机化），如果你在迭代set的过程中做累加并且有浮点运算，理论上结果可能有微小差异。整数统计不受影响，但涉及除法的时候要注意。

Counter的键数量比预期多：多半是清洗没做干净。跑一下counter.most_common()看完整列表，通常能发现全角空格、零宽字符、软连字符这些"隐形"字符。零宽字符 U+200B 尤其阴险，屏幕上看不见，统计里却实实在在占一个键。

6.3 性能问题排查

脚本跑得比预期慢很多：第一步上cProfile，别猜。字符统计的瓶颈通常在三个地方：Python 层循环、字符串拼接、正则编译。前者用Counter解决，中者用列表收集后join解决，后者把正则编译提到循环外面。

import cProfile cProfile.run("count_file('big.log')", sort="cumtime")

内存占用远超预期：检查是不是把整个文件读进来了，或者把中间结果全存在列表里。Counter本身占的内存跟不重复字符数成正比，中文语料几千个键没问题，但如果你的文本里混了大量随机 ID、URL、哈希值，不重复字符数可能上万，内存就会上去。

多进程版本反而更慢：前面说过，检查 IO 占比和分块策略。另外容器环境里multiprocessing的默认启动方式在部分平台上是spawn，子进程要重新导入模块，启动开销比fork大得多，小文件上这个开销能吃掉全部收益。

7. 一些踩坑之后总结的经验

写到这里，把几条不太适合塞进上面框架、但我觉得挺值钱的经验单独拎出来。

第一条，永远先在小样本上验证。我现在的习惯是，任何统计脚本写完之后，先拿一份 100 行左右、内容已知的样本跑一遍，人工核对前几个字符的计数，确认无误再上全量。这一步花两分钟，能省下后面半小时的排查。

第二条，把清洗逻辑和统计逻辑分开写。normalize(text)一个函数，count(text)一个函数，中间用清晰的输入输出约定串起来。这样调试的时候可以单独验证清洗结果对不对，也能在清洗逻辑改动时快速回归测试。我见过太多人把清洗和统计揉在一个大循环里，出问题只能一行行加 print。

第三条，注意str和bytes的边界。统计入口如果是从网络或者文件读的原始字节，尽早决定在哪里解码。我的习惯是在最外层解码成str，之后全程用str，避免下游某处突然要做encode/decode。唯一的例外是纯 ASCII 大文件，那种情况直接用bytes统计更快，但要在函数名或者注释里写清楚。

第四条，关于测试。字符统计的单元测试特别容易写，也特别容易漏。我一般会覆盖这几类输入：空字符串、纯 ASCII、纯中文、中英混排、带 emoji、带组合字符、带 BOM、带 CRLF。每类准备一两个小样本，断言结果即可。这套用例加起来不到五十行，但抓 bug 的效率极高。

最后分享一个我最近常用的调试小技巧：当统计结果看起来不对劲又找不到原因时，把文本的前 200 个字符用repr()打印出来。repr会把所有不可见字符、转义字符、非 ASCII 字符都显式展示，比眼睛盯着原文看有效一百倍。这个习惯帮我省下的时间，比任何性能优化技巧都多。