哈夫曼树构建时字符频次统计必须覆盖全部输入字节，需用const unsigned char*+size_t遍历原始数据以避免'\0'截断；频次数组宜用std::array确保全字节范围覆盖；优先队列比较器须稳定（如freq不等时按freq升序，相等时按ch升序）；编码表不可单独保存，必须序列化频次表或树结构至压缩流头部；比特流须位级写入/读取并记录末尾有效位数，严禁用std::string存二进制码。
哈夫曼树构建时，字符频率统计必须覆盖全部输入字节
直接用 std::map<char int></char> 统计频率看似合理，但会漏掉值为 0 的字节（比如 '\0'）——C++ 字符串中若含二进制数据或手动构造的 buffer，std::string 的 c_str() 在遇到首个 '\0' 就终止遍历。实际压缩二进制内容时，必须按字节长度逐字节处理：
- 用
const unsigned char*指针 +size_t len遍历原始数据，避免被空字符截断 - 频率映射类型建议用
std::array<int></int>，索引即字节值（0–255），天然支持全范围覆盖 - 若只压缩纯 ASCII 文本且明确不含
'\0'，可用std::string::data()+length()安全获取底层字节
优先队列比较器必须严格满足“非递减”语义，否则树结构错乱
用 std::priority_queue 构建哈夫曼树时，如果自定义比较器返回 a.freq > b.freq（小顶堆），但节点指针相等时未处理，会导致相同频率节点顺序不确定，生成的编码不唯一——这不是 bug，但解压端必须用完全相同的建树逻辑，否则无法还原。关键点：
- 比较器里必须对频率相等的节点补充次级排序（如按字符值、或按节点创建时间戳），保证稳定性
- 推荐写法：
return lhs->freq != rhs->freq ? lhs->freq > rhs->freq : lhs->ch > rhs->ch;（注意是>实现小顶堆） - 切勿用
std::less直接比较裸指针，不同编译器行为不一致
编码表生成后，必须序列化频率信息和树结构才能解压
仅保存哈夫曼编码字符串（如 "101100"）无法解压，因为解码器不知道每个码字对应哪个字符。常见做法是把频率表（或树结构）作为元数据前置写入压缩流：
- 最简方案：序列化
std::array<int></int>全部 256 个频次（每个 int 占 4 字节，共 1024 字节），解压时重建相同哈夫曼树 - 更省空间方案：只存非零频次项（
vector<pair char int>></pair>），但需额外记录总数和格式标识 - 注意：编码表本身（
map<char string></char>）不能直接存——它依赖建树过程，而建树过程受比较器稳定性影响，两端必须完全一致
位操作写入/读取时，缓冲区未对齐会导致末尾比特丢失
哈夫曼编码结果是比特流，不是字节流。常见错误是用 std::ofstream::write() 直接写入 std::string 形式的 "0101..."，这会把每个字符当 1 字节存（ASCII '0' 是 0x30），而非真正比特。正确做法：
- 编码阶段：用
uint8_t buf = 0和位移累计比特，每满 8 位 flush 到 vector；最后不足 8 位时，记录实际有效位数（存入头部） - 解码阶段：先读元数据→重建树→再按位读取：每次从当前字节取 1 bit（
(byte >> (7 - bit_pos)) & 1），bit_pos 循环 0–7 - 坑点：文件末尾若剩 3 位有效比特，必须在压缩数据前写入“补零位数=5”，否则解压器会多读 5 个 0 导致错误
哈夫曼压缩真正麻烦的不是算法本身，而是元数据怎么打包、比特怎么对齐、边界情况怎么处理——尤其当输入含 '\0' 或其他控制字符时，字符串类接口会悄悄丢数据，必须退回到 raw byte 层面操作。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
