huffman.encode不能直接用于字符串，因为go标准库无内置霍夫曼编码，实验包仅支持[]byte流，且utf-8多字节字符会被错误拆分为字节导致编码表错乱；必须按rune统计频次、手动构建霍夫曼树、生成编码表，并携带含编码表、原始长度等元数据的header才能无损编解码。
为什么 huffman.Encode 不能直接用在字符串上
Go 标准库没有内置霍夫曼编码，golang.org/x/exp/huffman 是实验包且只处理 []byte 流、不提供字符频次统计和符号映射构建逻辑。直接传入字符串会丢掉 UTF-8 多字节语义——比如中文字符被拆成多个 byte，导致编码表错乱。你得自己做「按符文（rune）统计」，而不是按字节。
实操建议：
- 用
strings.NewReader(s)+bufio.NewReader配合ReadRune()遍历，避免[]rune(s)一次性分配大 slice - 频次 map 必须是
map[rune]int，不是map[byte]int - 空字符串或单字符要单独判断：无法建树，直接返回原数据或带 header 的标记
如何手写最小堆构建霍夫曼树
Go 没有泛型优先队列（1.18 前），但你可以用 container/heap + 自定义结构体。关键不是堆本身，而是节点合并时的权重叠加逻辑是否匹配「字符频次总和」。
常见错误现象：Encode 后解码失败，或压缩率异常低——大概率是合并时用了节点数量而非频次累加，或者 rune 权重没传进叶子节点。
实操建议：
- 定义
type node struct { r rune; freq int; left, right *node }，叶子节点r != 0，内部节点r == 0 - 实现
Less(i, j int) bool时，先比freq，频次相同时比r（避免不稳定排序影响编码唯一性） - 建树完成后，用 DFS 生成
map[rune]string编码表，注意递归传参是当前路径字符串（如"0"/"1"），不是全局拼接
编码输出必须带元数据才能无损还原
只存 0/1 字符串无法解码：缺少编码表、原始长度、是否含非 ASCII 字符等信息。解压端不知道该用哪个 rune 对应哪段 bit，更无法知道最后一个 byte 是否补零。
使用场景：网络传输或文件存储时，header 必须可解析且定长优先。
实操建议：
- header 设计至少包含：
uint16编码表项数、每项的rune（4 字节）+ 编码长度（1 字节）+ bitstring（按字节对齐，高位在前） - 实际 bit 流用
bytes.Buffer+WriteBit()模拟（维护当前字节和 bit 位偏移），最后 flush 剩余 bits - 原始字符串长度（
int64）必须记录，否则解码到一半无法判断终止——尤其当多个相同高频字符导致短编码重复出现时
UTF-8 边界与 bit 流对齐的坑
把 "你好" 编成 "10110001" 这种字符串再转 []byte 是错的：它占 8 字节，而真实 bit 流可能只有 5 位。解压时若按字节读、未考虑末尾 padding，就会多解出垃圾符。
性能影响：每次写 1 bit 调用 WriteByte 开销大；兼容性影响：不同平台字节序对 header 无影响（全用 binary.BigEndian），但 bit 序必须统一为 MSB-first。
实操建议：
- bit 写入缓存用
var buf []byte+var bitOffset int，累计 8 位再append一个 byte - 最终 buffer 长度不是原始 bit 数，而是
(bitCount + 7) / 8；解码时需从 header 读出总 bit 数，而非 len(buffer) - 测试用例必含：
"a"（单字符）、"αβγ"（希腊字母）、"\x00\x01"（控制字符），验证 rune 边界和零值处理
真正难的不是算法，是把 rune 统计、bit 缓冲、header 序列化这三层胶水严丝合缝地粘住——少一处对齐，解压就静默错位。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
