哈夫曼树构建与编码需严格遵循贪心策略：优先合并最小频次节点；编码表递归生成时必须引用传递string避免O(n²)拷贝；内存释放须后序遍历，不可直接delete根节点；单字符或零频字符须特判处理。
为什么直接用 priority_queue 构建哈夫曼树时，operator 必须定义为“频率小的优先级高”？
因为 std::priority_queue 默认是最大堆，而哈夫曼算法要求每次取两个频率最小的节点合并——必须让最小频率节点始终在堆顶。若误写成按频率升序比较却没改容器行为（比如没传 std::greater），就会取到最大频率节点，编码长度爆炸式增长。
正确做法是：自定义比较结构体，返回 a.freq > b.freq；或直接用 priority_queue 配合 std::greater 语义。
- 错误示范：
bool operator → 实际得到最大堆，逻辑反了 - 正确示范：
struct Compare { bool operator()(Node* a, Node* b) { return a->freq > b->freq; } }; - 注意：比较函数操作的是指针，不是对象本身，否则堆里存的是临时拷贝，后续
delete会出错
构建编码表时递归遍历树为什么必须传入 string& code 而不是 string code？
每个叶子节点的编码是根到该叶的路径上所有边的标签（左0右1）拼接而成。若用值传递 string code，每次递归调用都会拷贝当前路径字符串，时间复杂度退化为 O(n²)，尤其在字符集大、深度深时明显卡顿。
引用传递避免重复拷贝，且在回溯时只需 code.pop_back() 即可撤销上一层的选择。
- 进入左子树前执行
code += '0'，返回前code.pop_back() - 右子树同理加
'1' - 遇到叶子节点时，把
code存入map即可 - 切忌在递归入口处声明新
string并传值——那等于每层都新建一个完整路径副本
buildHuffmanTree 返回 Node* 后，为什么不能立刻 delete 根节点来释放内存？
哈夫曼树的节点是动态分配的，但释放必须后序遍历完成，否则子节点指针变悬垂，导致多次 delete 或访问非法地址。常见崩溃信息如 double free or corruption 或 segmentation fault 很可能源于此。
- 必须单独写一个
deleteTree(Node* root)函数，递归地先删左右子树，再delete root - 若使用智能指针（如
unique_ptr），可自动管理，但要注意priority_queue不支持移动语义的裸指针容器混用，容易引发转移后原指针仍被使用的 bug - 调试时可用
valgrind --leak-check=full ./a.out检查是否遗漏释放
当输入字符频率全相等时，哈夫曼编码真的“最优”吗？
是的，但此时所有编码长度相等，退化为定长编码。例如 4 个字符各频次为 1，生成的树高度为 2，每个码长都是 2 bit（如 "00", "01", "10", "11"）。这符合哈夫曼“带权路径长度最小”的定义，只是没有压缩增益。
真正要警惕的是频次含 0 的情况：如果某字符出现 0 次，不应参与建树；否则会导致空叶子节点，后续编码表查找失败或 segfault。
- 预处理阶段应过滤掉频次为 0 的字符，
if (freq == 0) continue; - 若只剩一个非零字符（如全文件只有一种字节），需特判：直接赋编码 "0"，否则建树过程会因队列不足两个元素而崩溃
- 这个边界条件比理论描述更常出现在真实日志/二进制流压缩中
实际写的时候，最易漏掉的是单字符特判和内存释放顺序。前者让程序在极简输入下直接 abort，后者让 valgrind 报一堆 invalid read —— 表面运行正常，实则埋着释放后使用的雷。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
