因为priority_queue默认为最大堆，而哈夫曼算法需每次选取频率最小的两个节点合并，必须使用最小堆；若不重载operatorother.freq）或显式传入greater，将导致合并顺序错误、编码冗余甚至非最优前缀码。
为什么直接用 priority_queue 实现哈夫曼树构建时，节点比较逻辑必须重载小于号？
因为 priority_queue 默认是最大堆，而哈夫曼算法要求每次取频率最小的两个节点合并——必须用最小堆。不重载比较规则会导致取错节点，编码长度爆炸式增长，甚至生成非最优前缀码。
常见错误现象：priority_queue 编译失败，或运行时合并顺序混乱，最终 encode("a") 输出 5 位而非预期 2 位。
- 正确做法：定义结构体时重载
operator，返回freq > other.freq（注意是「大于」，因priority_queue底层用less，要骗它把小值“排前面”） - 更安全写法：显式传入
greater比较器，声明为priority_queue，前提是 Node已定义operator>或提供自定义仿函数 - 别用
map或set替代：它们按 key 排序但不支持 O(1) 取最小+O(log n) 插入合并节点，会拖慢整体 O(n log n) 复杂度
构建哈夫曼树后，如何避免递归遍历导致栈溢出或重复计算路径？
字符集大（如 UTF-8 中文）或频率极不均衡时，树可能退化成链表，纯递归生成编码易触发栈溢出；而每次查字符都从根遍历又浪费性能。
实际工程中应一次性生成完整码表，且用迭代代替递归：
- 用
stack模拟 DFS，入栈时拼接> "0"或"1"，遇到叶子节点就存入unordered_map - 不要在编码函数里实时遍历树：
encode(char c)应直接查预计算好的code_map[c]，否则单次查询复杂度从 O(1) 退化为 O(h) - 注意空字符（
'\0'）和控制字符：若输入含二进制数据，需用unsigned char作 map 键，否则char符号扩展会导致键错乱
buildHuffmanTree 函数里合并节点时，为什么新节点的频率必须是左右子树频率之和，且不能复用原节点内存？
哈夫曼算法贪心选择的正确性依赖于「子问题最优性」：每次合并的两个最小频叶子/子树，其父节点频率即二者和，这个值将参与后续比较。若只存指针不更新频率，后续 priority_queue 无法正确排序。
容易踩的坑：
- 误写成
new Node(left->freq)忘加right->freq：导致合并后节点权重失真，树结构错误，压缩率骤降 - 复用已有
Node对象（如把左节点的freq改成和，右节点设为子节点）：破坏堆内节点一致性，priority_queue内部堆序已失效，后续pop()行为未定义 - 没释放中间节点内存：虽然构建过程临时节点多，但 C++ 要求明确
delete所有new出的节点，否则泄漏；建议用智能指针或在析构函数中后序遍历释放
贪心性质在哪儿体现？为什么不能用动态规划？
哈夫曼算法的贪心体现在：每一步都无条件选择当前可用的两个最小频率节点合并，不回溯、不试探其他组合。这成立的前提是「最优前缀码必存在一棵树，其两个最小频率字符处于最深层且互为兄弟」——这是可证明的交换论证结论。
动态规划理论上可行（状态为字符子集），但状态数达 O(2ⁿ)，n=256 时完全不可行；而贪心解法稳定 O(n log n)，且严格最优。
关键提醒：
- 贪心选择必须基于原始频率，不是归一化后的概率：输入
{'a':5, 'b':9, 'c':12}和{'a':0.19, 'b':0.35, 'c':0.46}构建结果相同，但浮点误差可能导致priority_queue排序错位，务必用整型频次 - 若字符频率全相同（如等长编码场景），哈夫曼树不唯一，但任意合法构造都达到理论熵下限，无需强求特定形态
- 真实压缩库（如 zlib）不用纯哈夫曼，而是结合 LZ77 预处理+哈夫曼编码，因为单独哈夫曼对重复模式不敏感
真正难的是边界：空输入、单字符、频率为零的字符、超长字符串导致路径字符串拼接开销——这些在教学代码里常被忽略，但在嵌入式或流式压缩中会立刻暴露。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
