简介这份资源面向学习数据结构与算法的高校学生及C语言开发者聚焦哈夫曼编码在文件压缩中的完整实现可用于课程作业参考、算法理解与项目实践。压缩包共93个文件约2.87MB包含c与cpp源码、h头文件、exe可执行程序、doc实验文档、txt测试文本及dsp、dsw等工程配置与编译中间文件覆盖从源码到可运行程序的完整链路。资源按程序编写阶段分为多个版本既有不含命令行命令的基础版也有含cmd命令的进阶版还提供带图形界面的MFC工程方便对照不同实现思路。核心功能是用哈夫曼树对ASCII文件进行压缩与解码编码后生成实际压缩文件并附带界面交互效果代码功能完善。已有675人学习下载适合需要理解哈夫曼树构建、编码表生成、压缩率验证及解码还原流程的读者也可作为数据结构课程设计的参考范例。1. 哈夫曼编码做文件压缩为什么它是最值得手写的压缩算法你有没有遇到过这种场景一份纯文本日志文件明明内容全是 ASCII 字符体积却大得离谱传输慢、存储贵用通用压缩工具压完又觉得“黑匣子”一样不知道里面发生了什么。哈夫曼编码-文件压缩就是解决这类问题的经典方案它根据字符出现频率构建一棵最优二叉树频率高的字符用短码频率低的用长码从而让整体编码长度最短。它适合谁适合想真正理解压缩原理的开发者、需要自己实现轻量压缩模块的嵌入式方向从业者以及准备面试时被问到“手写一个压缩算法”的人。我见过太多人背得出“左0右1”却写不出能跑通二进制文件的完整流程这篇就把这条链路从头到尾走一遍。2. 哈夫曼树怎么建从频率表到前缀码的完整推演2.1 为什么必须用最小堆而不是普通排序哈夫曼树的核心操作是每次从候选节点中取出频率最小的两个节点合并成一个新节点新节点频率为两者之和再放回候选集合。如果每次都用普通数组排序时间复杂度是 O(n²)用最小堆优先队列可以降到 O(n log n)。对于几百种字符的文本文件这个差距在几十毫秒级别但如果是二进制文件按字节统计256 个叶子节点差距会放大到肉眼可见。我一般会直接用 Python 的heapq它是最小堆的标准实现。注意一个细节堆里比较的是频率但频率相同的节点之间需要有一个稳定的比较规则否则不同运行环境可能生成不同的树结构。虽然编码长度不变但具体码字会变做校验时会翻车。import heapq from collections import Counter class Node: __slots__ (char, freq, left, right) def __init__(self, char, freq, leftNone, rightNone): self.char char # 叶子节点存字符内部节点为 None self.freq freq self.left left self.right right # 关键定义比较规则频率相同按字符序保证树结构稳定 def __lt__(self, other): if self.freq ! other.freq: return self.freq other.freq # 内部节点 char 为 None统一用 -1 参与比较 return (self.char or -1) (other.char or -1) def build_huffman_tree(data: bytes): # 统计字节频率data 是原始二进制内容 freq Counter(data) if len(freq) 1: # 只有一种字节时直接构造一个根节点带左孩子 only_byte next(iter(freq)) return Node(None, freq[only_byte], Node(only_byte, freq[only_byte])) heap [Node(b, f) for b, f in freq.items()] heapq.heapify(heap) while len(heap) 1: left heapq.heappop(heap) right heapq.heappop(heap) merged Node(None, left.freq right.freq, left, right) heapq.heappush(heap, merged) return heap[0]这段代码里__lt__是血泪经验不定义它Python 3 在频率相同时会尝试比较 Node 对象直接抛 TypeError。__slots__是为了省内存处理大文件时每个节点少几十字节累积起来很可观。len(freq) 1是边界情况所有字节相同哈夫曼树退化成单边树编码长度固定为 1 位但如果不特殊处理堆里只有一个节点循环不执行返回的树没有左右孩子后续编码会出错。2.2 递归生成编码表深度优先与码字拼接树建好后从根节点出发向左走记 0向右走记 1走到叶子节点就得到该字符的哈夫曼码。递归是最自然的写法但要注意 Python 递归深度限制256 个叶子节点的树深度最坏情况是 255远低于默认的 1000所以安全。def build_code_table(root): table {} def dfs(node, code): if node is None: return if node.char is not None: # 叶子节点记录编码单字节文件时 code 可能为空补 0 table[node.char] code if code else 0 return dfs(node.left, code 0) dfs(node.right, code 1) dfs(root, ) return tablecode 0这种字符串拼接在深度大时会产生大量临时对象但 256 个叶子节点规模下完全可接受。如果处理的是 Unicode 字符集叶子可能上万那就该用整数位操作代替字符串这是后话。编码表建好后每个字节对应一个 01 字符串比如{65: 00, 66: 010, ...}。2.3 把 01 串写进二进制文件位操作与填充这是最容易翻车的一步。编码表给出的是字符串但文件必须按位写入。Python 里没有原生位流需要自己维护一个字节缓冲区。def encode_data(data: bytes, table: dict) - bytes: bit_buffer 0 bit_count 0 output bytearray() for byte in data: code table[byte] for bit in code: bit_buffer (bit_buffer 1) | (1 if bit 1 else 0) bit_count 1 if bit_count 8: output.append(bit_buffer) bit_buffer 0 bit_count 0 # 处理剩余不足 8 位的部分 if bit_count 0: bit_buffer (8 - bit_count) output.append(bit_buffer) return bytes(output)逻辑说明bit_buffer累积位每满 8 位就输出一个字节。最后如果还有剩余位左移到高位对齐低位补 0。这里必须记录填充了多少位否则解码时会把填充的 0 当成有效数据。常见做法是在文件头写入原始数据长度字节数解码时按长度截断而不是依赖填充位数。参数上bit_count的范围是 0 到 7填充位数就是8 - bit_count当 bit_count 0 时。3. 解码与文件格式怎么让压缩结果可还原3.1 文件头设计频率表还是树结构解码需要哈夫曼树。有两种方案一是把频率表写入文件头解码端重建树二是直接序列化树结构。频率表更紧凑256 个字节的频率值每个用 4 字节整数就是 1KB对压缩收益有影响。我一般用变长编码存频率先写频率表的条目数2 字节然后每项写字节值1 字节和频率4 字节。对于小文件这 1KB 开销可能让压缩后反而变大所以需要判断如果压缩后大小 原始大小就直接存原始数据文件头加一个标志位。import struct def write_compressed_file(path, data, table, encoded): freq Counter(data) with open(path, wb) as f: # 标志位1 表示压缩数据0 表示原始数据 if len(encoded) 2 len(freq) * 5 len(data): f.write(struct.pack(B, 0)) f.write(data) return f.write(struct.pack(B, 1)) f.write(struct.pack(H, len(freq))) # 频率表条目数 for byte, count in freq.items(): f.write(struct.pack(BI, byte, count)) f.write(struct.pack(I, len(data))) # 原始长度用于解码截断 f.write(encoded)H是大端 2 字节无符号整数BI是 1 字节加 4 字节。用大端是为了跨平台一致。原始长度用 4 字节支持最大 4GB 文件对大多数场景够用。如果处理更大文件换成 8 字节Q。3.2 解码流程从位流还原字节解码时先读标志位如果是 0 就直接读原始数据。如果是 1读频率表重建哈夫曼树然后读原始长度最后逐位遍历编码数据从树根往下走遇到叶子就输出一个字节直到输出够原始长度。def decode_file(path): with open(path, rb) as f: flag struct.unpack(B, f.read(1))[0] if flag 0: return f.read() entry_count struct.unpack(H, f.read(2))[0] freq {} for _ in range(entry_count): byte, count struct.unpack(BI, f.read(5)) freq[byte] count original_len struct.unpack(I, f.read(4))[0] # 重建哈夫曼树 heap [Node(b, c) for b, c in freq.items()] heapq.heapify(heap) while len(heap) 1: left heapq.heappop(heap) right heapq.heappop(heap) heapq.heappush(heap, Node(None, left.freq right.freq, left, right)) root heap[0] # 逐位解码 result bytearray() node root while len(result) original_len: byte f.read(1) if not byte: break bits bin(byte[0])[2:].zfill(8) for bit in bits: node node.left if bit 0 else node.right if node.char is not None: result.append(node.char) node root if len(result) original_len: break return bytes(result)注意zfill(8)保证每个字节都按 8 位处理否则bin(1)得到1而不是00000001解码全乱。这是新手最容易踩的坑之一。3.3 压缩效果验证用真实文件跑一遍拿一个 1MB 的英文文本文件测试字符分布符合自然语言规律哈夫曼编码通常能压到原始大小的 55% 到 65%。如果是二进制文件字节分布均匀压缩率接近 100%甚至因为文件头开销而变大。所以哈夫曼编码适合频率分布不均匀的数据纯文本、日志、源代码都是好场景。# 生成测试文件 python -c import random; open(test.txt,w).write(.join(random.choice(abcdefghijklmnopqrstuvwxyz ) for _ in range(1000000))) # 压缩 python huffman.py compress test.txt test.huff # 解压 python huffman.py decompress test.huff test_restored.txt # 校验 diff test.txt test_restored.txt echo OK如果diff没有输出且打印 OK说明整个链路正确。我习惯在压缩后打印原始大小、压缩后大小、压缩率方便快速判断效果。4. 避坑与排查哈夫曼编码实现中最容易翻车的 5 个点4.1 现象解压后文件比原始文件多出几个字节原因编码时最后不足 8 位的填充位没有在解码时正确截断。如果解码端不知道原始长度就会把填充的 0 也解成字符。解决文件头必须写入原始字节长度解码时严格按长度停止而不是读到文件尾。4.2 现象频率相同的字符在不同机器上编码结果不一致原因堆比较时没有定义稳定的次级比较规则Python 的heapq在频率相同时依赖对象默认比较而对象地址在不同运行中不同。解决在Node.__lt__里加入字符值比较内部节点用固定值如 -1参与比较保证全序。4.3 现象处理空文件或单字节文件时程序崩溃原因空文件没有频率表堆为空单字节文件堆里只有一个节点循环不执行树没有左右孩子。解决空文件直接写标志位 0 存原始数据单字节文件特殊构造根节点编码固定为 0。4.4 现象压缩后文件反而变大原因小文件或高频均匀分布的数据频率表开销超过压缩收益。解决压缩前预估如果len(encoded) 文件头开销 len(data)直接存原始数据标志位设为 0。这个判断逻辑要放在写文件之前。4.5 现象解码时bin(byte)得到0b1而不是 8 位原因Python 的bin()不会补前导零。解决用format(byte, 08b)或bin(byte)[2:].zfill(8)。这个坑我见过至少三次每次都是解码结果错位。5. 进阶技巧用规范哈夫曼和位操作把性能再提一档如果你已经跑通了上面的流程下一步可以关注两个方向规范哈夫曼编码Canonical Huffman Coding和整数位缓冲。规范哈夫曼的核心思想是不传输树结构只传输每个码字的长度然后按固定规则重建码字。规则是相同长度的码字按字符值升序分配连续码字长度短的码字先分配长度每增加 1码字左移 1 位再继续分配。这样文件头只需要存 256 个码长每个 1 字节比存频率表更紧凑而且解码时可以用查表法加速。def build_canonical_codes(lengths: dict): # lengths: {byte: code_length} sorted_items sorted(lengths.items(), keylambda x: (x[1], x[0])) code 0 prev_len 0 table {} for byte, length in sorted_items: code (length - prev_len) table[byte] format(code, 0{}b.format(length)) code 1 prev_len length return table这个函数生成的码字和原始哈夫曼树生成的码字长度完全一致但具体 01 串可能不同不影响压缩率。解码时先读码长表重建规范码表然后逐位匹配。匹配可以用字典树也可以用一个长度为2^max_length的数组做查表max_length 通常不超过 32数组大小可控。另一个技巧是用整数代替字符串做位缓冲。上面的encode_data里每个位都做字符串遍历Python 层循环慢。可以预先把每个字节的编码转成整数和长度然后批量移位。def encode_fast(data: bytes, table: dict): # 预计算{byte: (code_int, code_len)} int_table {} for byte, code_str in table.items(): int_table[byte] (int(code_str, 2), len(code_str)) buffer 0 bits 0 output bytearray() for byte in data: code, length int_table[byte] buffer (buffer length) | code bits length while bits 8: bits - 8 output.append((buffer bits) 0xFF) if bits 0: output.append((buffer (8 - bits)) 0xFF) return bytes(output)这个版本比字符串版快 3 到 5 倍处理 10MB 文件时差距明显。注意buffer在 Python 里是任意精度整数不会溢出但位移操作后要及时把已输出的高位清掉否则 buffer 会越来越大。上面的写法用bits控制有效位数buffer只保留未输出的低位实际运行时buffer不会超过 64 位。我自己的习惯是先用字符串版把逻辑跑通确认压缩解压一致再换成整数版做性能优化。直接写整数版容易在位运算细节上翻车调试成本高。另外规范哈夫曼的码长表可以用行程编码再压一次但那是另一个话题了。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/16 20:07:40 · 阅读 1.2k 哈夫曼编码文件压缩实战：从建树到解码的完整实现
简介这份资源面向学习数据结构与算法的高校学生及C语言开发者聚焦哈夫曼编码在文件压缩中的完整实现可用于课程作业参考、算法理解与项目实践。压缩包共93个文件约2.87MB包含c与cpp源码、h头文件、exe可执行程序、doc实验文档、txt测试文本及dsp、dsw等工程配置与编译中间文件覆盖从源码到可运行程序的完整链路。资源按程序编写阶段分为多个版本既有不含命令行命令的基础版也有含cmd命令的进阶版还提供带图形界面的MFC工程方便对照不同实现思路。核心功能是用哈夫曼树对ASCII文件进行压缩与解码编码后生成实际压缩文件并附带界面交互效果代码功能完善。已有675人学习下载适合需要理解哈夫曼树构建、编码表生成、压缩率验证及解码还原流程的读者也可作为数据结构课程设计的参考范例。1. 哈夫曼编码做文件压缩为什么它是最值得手写的压缩算法你有没有遇到过这种场景一份纯文本日志文件明明内容全是 ASCII 字符体积却大得离谱传输慢、存储贵用通用压缩工具压完又觉得“黑匣子”一样不知道里面发生了什么。哈夫曼编码-文件压缩就是解决这类问题的经典方案它根据字符出现频率构建一棵最优二叉树频率高的字符用短码频率低的用长码从而让整体编码长度最短。它适合谁适合想真正理解压缩原理的开发者、需要自己实现轻量压缩模块的嵌入式方向从业者以及准备面试时被问到“手写一个压缩算法”的人。我见过太多人背得出“左0右1”却写不出能跑通二进制文件的完整流程这篇就把这条链路从头到尾走一遍。2. 哈夫曼树怎么建从频率表到前缀码的完整推演2.1 为什么必须用最小堆而不是普通排序哈夫曼树的核心操作是每次从候选节点中取出频率最小的两个节点合并成一个新节点新节点频率为两者之和再放回候选集合。如果每次都用普通数组排序时间复杂度是 O(n²)用最小堆优先队列可以降到 O(n log n)。对于几百种字符的文本文件这个差距在几十毫秒级别但如果是二进制文件按字节统计256 个叶子节点差距会放大到肉眼可见。我一般会直接用 Python 的heapq它是最小堆的标准实现。注意一个细节堆里比较的是频率但频率相同的节点之间需要有一个稳定的比较规则否则不同运行环境可能生成不同的树结构。虽然编码长度不变但具体码字会变做校验时会翻车。import heapq from collections import Counter class Node: __slots__ (char, freq, left, right) def __init__(self, char, freq, leftNone, rightNone): self.char char # 叶子节点存字符内部节点为 None self.freq freq self.left left self.right right # 关键定义比较规则频率相同按字符序保证树结构稳定 def __lt__(self, other): if self.freq ! other.freq: return self.freq other.freq # 内部节点 char 为 None统一用 -1 参与比较 return (self.char or -1) (other.char or -1) def build_huffman_tree(data: bytes): # 统计字节频率data 是原始二进制内容 freq Counter(data) if len(freq) 1: # 只有一种字节时直接构造一个根节点带左孩子 only_byte next(iter(freq)) return Node(None, freq[only_byte], Node(only_byte, freq[only_byte])) heap [Node(b, f) for b, f in freq.items()] heapq.heapify(heap) while len(heap) 1: left heapq.heappop(heap) right heapq.heappop(heap) merged Node(None, left.freq right.freq, left, right) heapq.heappush(heap, merged) return heap[0]这段代码里__lt__是血泪经验不定义它Python 3 在频率相同时会尝试比较 Node 对象直接抛 TypeError。__slots__是为了省内存处理大文件时每个节点少几十字节累积起来很可观。len(freq) 1是边界情况所有字节相同哈夫曼树退化成单边树编码长度固定为 1 位但如果不特殊处理堆里只有一个节点循环不执行返回的树没有左右孩子后续编码会出错。2.2 递归生成编码表深度优先与码字拼接树建好后从根节点出发向左走记 0向右走记 1走到叶子节点就得到该字符的哈夫曼码。递归是最自然的写法但要注意 Python 递归深度限制256 个叶子节点的树深度最坏情况是 255远低于默认的 1000所以安全。def build_code_table(root): table {} def dfs(node, code): if node is None: return if node.char is not None: # 叶子节点记录编码单字节文件时 code 可能为空补 0 table[node.char] code if code else 0 return dfs(node.left, code 0) dfs(node.right, code 1) dfs(root, ) return tablecode 0这种字符串拼接在深度大时会产生大量临时对象但 256 个叶子节点规模下完全可接受。如果处理的是 Unicode 字符集叶子可能上万那就该用整数位操作代替字符串这是后话。编码表建好后每个字节对应一个 01 字符串比如{65: 00, 66: 010, ...}。2.3 把 01 串写进二进制文件位操作与填充这是最容易翻车的一步。编码表给出的是字符串但文件必须按位写入。Python 里没有原生位流需要自己维护一个字节缓冲区。def encode_data(data: bytes, table: dict) - bytes: bit_buffer 0 bit_count 0 output bytearray() for byte in data: code table[byte] for bit in code: bit_buffer (bit_buffer 1) | (1 if bit 1 else 0) bit_count 1 if bit_count 8: output.append(bit_buffer) bit_buffer 0 bit_count 0 # 处理剩余不足 8 位的部分 if bit_count 0: bit_buffer (8 - bit_count) output.append(bit_buffer) return bytes(output)逻辑说明bit_buffer累积位每满 8 位就输出一个字节。最后如果还有剩余位左移到高位对齐低位补 0。这里必须记录填充了多少位否则解码时会把填充的 0 当成有效数据。常见做法是在文件头写入原始数据长度字节数解码时按长度截断而不是依赖填充位数。参数上bit_count的范围是 0 到 7填充位数就是8 - bit_count当 bit_count 0 时。3. 解码与文件格式怎么让压缩结果可还原3.1 文件头设计频率表还是树结构解码需要哈夫曼树。有两种方案一是把频率表写入文件头解码端重建树二是直接序列化树结构。频率表更紧凑256 个字节的频率值每个用 4 字节整数就是 1KB对压缩收益有影响。我一般用变长编码存频率先写频率表的条目数2 字节然后每项写字节值1 字节和频率4 字节。对于小文件这 1KB 开销可能让压缩后反而变大所以需要判断如果压缩后大小 原始大小就直接存原始数据文件头加一个标志位。import struct def write_compressed_file(path, data, table, encoded): freq Counter(data) with open(path, wb) as f: # 标志位1 表示压缩数据0 表示原始数据 if len(encoded) 2 len(freq) * 5 len(data): f.write(struct.pack(B, 0)) f.write(data) return f.write(struct.pack(B, 1)) f.write(struct.pack(H, len(freq))) # 频率表条目数 for byte, count in freq.items(): f.write(struct.pack(BI, byte, count)) f.write(struct.pack(I, len(data))) # 原始长度用于解码截断 f.write(encoded)H是大端 2 字节无符号整数BI是 1 字节加 4 字节。用大端是为了跨平台一致。原始长度用 4 字节支持最大 4GB 文件对大多数场景够用。如果处理更大文件换成 8 字节Q。3.2 解码流程从位流还原字节解码时先读标志位如果是 0 就直接读原始数据。如果是 1读频率表重建哈夫曼树然后读原始长度最后逐位遍历编码数据从树根往下走遇到叶子就输出一个字节直到输出够原始长度。def decode_file(path): with open(path, rb) as f: flag struct.unpack(B, f.read(1))[0] if flag 0: return f.read() entry_count struct.unpack(H, f.read(2))[0] freq {} for _ in range(entry_count): byte, count struct.unpack(BI, f.read(5)) freq[byte] count original_len struct.unpack(I, f.read(4))[0] # 重建哈夫曼树 heap [Node(b, c) for b, c in freq.items()] heapq.heapify(heap) while len(heap) 1: left heapq.heappop(heap) right heapq.heappop(heap) heapq.heappush(heap, Node(None, left.freq right.freq, left, right)) root heap[0] # 逐位解码 result bytearray() node root while len(result) original_len: byte f.read(1) if not byte: break bits bin(byte[0])[2:].zfill(8) for bit in bits: node node.left if bit 0 else node.right if node.char is not None: result.append(node.char) node root if len(result) original_len: break return bytes(result)注意zfill(8)保证每个字节都按 8 位处理否则bin(1)得到1而不是00000001解码全乱。这是新手最容易踩的坑之一。3.3 压缩效果验证用真实文件跑一遍拿一个 1MB 的英文文本文件测试字符分布符合自然语言规律哈夫曼编码通常能压到原始大小的 55% 到 65%。如果是二进制文件字节分布均匀压缩率接近 100%甚至因为文件头开销而变大。所以哈夫曼编码适合频率分布不均匀的数据纯文本、日志、源代码都是好场景。# 生成测试文件 python -c import random; open(test.txt,w).write(.join(random.choice(abcdefghijklmnopqrstuvwxyz ) for _ in range(1000000))) # 压缩 python huffman.py compress test.txt test.huff # 解压 python huffman.py decompress test.huff test_restored.txt # 校验 diff test.txt test_restored.txt echo OK如果diff没有输出且打印 OK说明整个链路正确。我习惯在压缩后打印原始大小、压缩后大小、压缩率方便快速判断效果。4. 避坑与排查哈夫曼编码实现中最容易翻车的 5 个点4.1 现象解压后文件比原始文件多出几个字节原因编码时最后不足 8 位的填充位没有在解码时正确截断。如果解码端不知道原始长度就会把填充的 0 也解成字符。解决文件头必须写入原始字节长度解码时严格按长度停止而不是读到文件尾。4.2 现象频率相同的字符在不同机器上编码结果不一致原因堆比较时没有定义稳定的次级比较规则Python 的heapq在频率相同时依赖对象默认比较而对象地址在不同运行中不同。解决在Node.__lt__里加入字符值比较内部节点用固定值如 -1参与比较保证全序。4.3 现象处理空文件或单字节文件时程序崩溃原因空文件没有频率表堆为空单字节文件堆里只有一个节点循环不执行树没有左右孩子。解决空文件直接写标志位 0 存原始数据单字节文件特殊构造根节点编码固定为 0。4.4 现象压缩后文件反而变大原因小文件或高频均匀分布的数据频率表开销超过压缩收益。解决压缩前预估如果len(encoded) 文件头开销 len(data)直接存原始数据标志位设为 0。这个判断逻辑要放在写文件之前。4.5 现象解码时bin(byte)得到0b1而不是 8 位原因Python 的bin()不会补前导零。解决用format(byte, 08b)或bin(byte)[2:].zfill(8)。这个坑我见过至少三次每次都是解码结果错位。5. 进阶技巧用规范哈夫曼和位操作把性能再提一档如果你已经跑通了上面的流程下一步可以关注两个方向规范哈夫曼编码Canonical Huffman Coding和整数位缓冲。规范哈夫曼的核心思想是不传输树结构只传输每个码字的长度然后按固定规则重建码字。规则是相同长度的码字按字符值升序分配连续码字长度短的码字先分配长度每增加 1码字左移 1 位再继续分配。这样文件头只需要存 256 个码长每个 1 字节比存频率表更紧凑而且解码时可以用查表法加速。def build_canonical_codes(lengths: dict): # lengths: {byte: code_length} sorted_items sorted(lengths.items(), keylambda x: (x[1], x[0])) code 0 prev_len 0 table {} for byte, length in sorted_items: code (length - prev_len) table[byte] format(code, 0{}b.format(length)) code 1 prev_len length return table这个函数生成的码字和原始哈夫曼树生成的码字长度完全一致但具体 01 串可能不同不影响压缩率。解码时先读码长表重建规范码表然后逐位匹配。匹配可以用字典树也可以用一个长度为2^max_length的数组做查表max_length 通常不超过 32数组大小可控。另一个技巧是用整数代替字符串做位缓冲。上面的encode_data里每个位都做字符串遍历Python 层循环慢。可以预先把每个字节的编码转成整数和长度然后批量移位。def encode_fast(data: bytes, table: dict): # 预计算{byte: (code_int, code_len)} int_table {} for byte, code_str in table.items(): int_table[byte] (int(code_str, 2), len(code_str)) buffer 0 bits 0 output bytearray() for byte in data: code, length int_table[byte] buffer (buffer length) | code bits length while bits 8: bits - 8 output.append((buffer bits) 0xFF) if bits 0: output.append((buffer (8 - bits)) 0xFF) return bytes(output)这个版本比字符串版快 3 到 5 倍处理 10MB 文件时差距明显。注意buffer在 Python 里是任意精度整数不会溢出但位移操作后要及时把已输出的高位清掉否则 buffer 会越来越大。上面的写法用bits控制有效位数buffer只保留未输出的低位实际运行时buffer不会超过 64 位。我自己的习惯是先用字符串版把逻辑跑通确认压缩解压一致再换成整数版做性能优化。直接写整数版容易在位运算细节上翻车调试成本高。另外规范哈夫曼的码长表可以用行程编码再压一次但那是另一个话题了。希望帮到你。本文还有配套的精品资源点击获取