哈夫曼编码必须分步构建树、生成码表、映射替换；用priority_queue需自定义比较器return a->freq > b->freq实现小顶堆，传Node*而非值类型，空/单字符时while(size>1)安全，编码表生成须引用传递string&或vector<bool>&避免O(n²)拷贝，压缩输出须逐bit写入字节数组并记录有效位数。
哈夫曼编码不是“对字符串直接调用一个函数就能完成”的操作，它必须分步构造树、生成码表、再映射替换——跳过任一环节都会导致解码失败或压缩无效。
怎么用 priority_queue 正确构建最小堆
默认的 std::priority_queue 是大顶堆，直接塞进去会按频次降序排列，合并时总挑出最大的两个节点，结果完全反了。必须显式指定比较逻辑：
- 用
std::greater<Node*>：前提是Node重载了operator<，且定义为return lhs->freq < rhs->freq - 或传入自定义比较器（更推荐）：
struct Compare { bool operator()(Node* a, Node* b) { return a->freq > b->freq; } }，注意这里是>，因为priority_queue的“比较器返回 true 表示应被下沉”，所以要反过来写 - 别用
Node值类型入队——拷贝开销大且无法建树；必须用Node*或std::shared_ptr<Node> - 空字符串或单字符输入时，堆里只剩一个节点，
while (minHeap.size() > 1)才安全，不能写成!= 1
生成编码表时为什么不能只靠 string += "0"
递归 DFS 中频繁拼接 std::string 会导致大量内存分配和拷贝，尤其在深度较大时（比如 200+ 层），性能断崖式下降。更关键的是，它掩盖了路径回溯问题：
- 进入左子树后加
'0'，但递归返回时没删掉，下一次进右子树就会多带一个'0' - 正确做法是传入引用参数
std::vector<bool>& path，进左 push_back(false)，进右 push_back(true)，返回前 pop_back()；或者用std::string& prefix配合prefix.reserve(256)+prefix.push_back('0')+prefix.pop_back() - 判断叶子节点必须严格用
!node->left && !node->right，不能只看node->ch是否有值——内部节点也可能临时存了字符
压缩输出为什么不能直接拼接 std::string 形式的编码
把 "101"、"0"、"1100" 连成 "10101100" 看似自然，但解压时根本无法切分：“1010” 是一个字符还是 “10”+“10”？哈夫曼码没有固定边界。
立即学习“C++免费学习笔记（深入）”；
- 必须逐 bit 写入字节数组：
std::vector<uint8_t>，维护当前字节和已写位数（0–7） - 每写一位：左移对齐 + 位或，满 8 位就 push 到 vector，重置
- 末尾不足一字节的部分必须保留，并额外记录“有效位数”（如最后用了 5 位，就在头部存数字 5）
- 若原始数据含
'\0'，频次统计必须用unsigned char作 map 键，否则char(-1)会被截断或符号扩展，导致漏统计
最易被忽略的是：哈夫曼树本身不保存在压缩结果里，解压时得靠频次表重建——所以频次表的序列化必须稳定（比如按字符 ASCII 升序写入），否则同一输入在不同机器上可能生成结构不同的树，导致解压失败。
