直接用 priority_queue 构建哈夫曼树易错，因其默认为大根堆，而算法需小根堆以每次合并最小频次节点；须自定义比较逻辑、正确设置节点结构（left/right/freq/ch）、处理边界情况（如空输入、单字符），并确保编码生成时路径回溯无误。
为什么直接用 priority_queue 构建哈夫曼树容易出错
因为默认的 std::priority_queue 是大根堆，而哈夫曼算法必须每次取频率最小的两个节点合并——得用小根堆。不重载比较逻辑的话，top() 返回的是最大值，合并顺序全乱，生成的树既不最优也不满足前缀码要求。
实操建议：
- 定义节点结构体时，显式提供
operator，让频率小的排在前面（注意：优先队列底层是“大顶堆语义”，所以要返回 <code>a.freq > b.freq才能实现小顶效果） - 不要用
greater<int></int>简单套用，因为节点是自定义类型，必须写完整比较逻辑 - 合并后新节点的频率必须是左右子树频率之和，且左右子节点指针不能为
nullptr后再参与下一轮合并
HuffmanNode 的构造必须支持带权合并与路径回溯
单纯存 freq 和 ch 不够，后续生成编码时要从叶子往根反向拼接字符串。所以每个节点至少得有：left、right、freq、ch（仅叶子有效），以及可选的 parent 或统一靠递归遍历处理。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
- 把所有节点都塞进队列后，合并过程中丢失了原始字符到叶子节点的映射，导致最后无法查表生成编码
- 非叶子节点的
ch被误设为某个字符，造成解码歧义 - 构建完树没保存根节点指针，后续遍历无从下手
推荐做法：只在叶子节点设置 ch，内部节点 ch 设为 '<p>推荐做法：只在叶子节点设置 <code>ch，内部节点 ch 设为 '\0'；构建完成后，用 DFS 从根出发，左走记 '0'、右走记 '1'，遇到 ch != '\0' 就存入 map<char string></char>。
'0'、右走记 '1'，遇到 ch != '<p>推荐做法：只在叶子节点设置 <code>ch，内部节点 ch 设为 '\0'；构建完成后，用 DFS 从根出发，左走记 '0'、右走记 '1'，遇到 ch != '\0' 就存入 map<char string></char>。' 就存入 map<char string></char>。
贪心选择性质在代码里怎么体现——不是排序，是动态最小提取
哈夫曼算法的贪心性不在初始排序，而在每一步都从当前所有可用子树中挑出两个权重最小的合并。这决定了不能用静态数组+冒泡模拟，而必须依赖支持高效插入/删除最小元的数据结构。
性能与兼容性影响：
-
priority_queue平均O(log n)插入/弹出，总时间O(n log n)，比手写堆或multiset更轻量 - 若输入含 0 频率字符（比如预占位），需提前过滤，否则会生成孤立零权子树，破坏树结构完整性
- C++20 前不支持直接用
auto推导priority_queue比较器类型，老项目建议用仿函数或 lambda 绑定到类型别名
编码生成阶段最容易漏掉的边界：空字符、重复字符、单字符输入
当输入字符串为空或只有一个字符时，哈夫曼树退化为单节点。此时若强行按左右子树递归，会触发空指针解引用；若未特殊处理，生成的编码可能为空串或全 '0'，导致解码失败。
使用场景下的关键判断：
- 输入长度为 0 → 直接返回空
map - 输入所有字符相同（如
"aaaa"）→ 树高为 1，唯一叶子节点编码应为"0"（不是空串），否则解码器无法区分“有数据”和“无数据” - 字符集含
'\0'或控制字符 → 注意string构造和输出时不要被截断，建议用cout.write(s.data(), s.size())
真正难的不是合并逻辑，而是把字符频次统计、树构建、编码生成、异常输入兜底这四层严丝合缝地串起来——尤其当你要把这套逻辑嵌进网络协议的压缩模块时，任何一个环节少个 if (node->left) 检查，上线后就可能卡死在某个特定 payload 上。
