因为默认priority_queue是大根堆，而哈夫曼算法需每次取最小频次节点合并；不重载比较逻辑会导致合并顺序错误、WPL增大、编码非前缀码。
为什么直接用 priority_queue 实现哈夫曼树构建时，节点比较逻辑容易出错
因为哈夫曼算法依赖「频率最小的两个节点优先合并」，而 C++ 默认 priority_queue 是最大堆；若不自定义比较器，会把高频节点先弹出，结果完全反了。
常见错误现象：priority_queue<node></node> 编译通过但生成的编码长度反而更长，甚至出现非前缀码（比如 "0" 和 "01" 同时存在）。
正确做法是让堆顶始终是最小频率节点：
struct Node {
char ch;
int freq;
Node* left;
Node* right;
Node(char c, int f) : ch(c), freq(f), left(nullptr), right(nullptr) {}
};
struct Compare {
bool operator()(const Node* a, const Node* b) {
return a->freq > b->freq; // 注意：> 表示小顶堆
}
};
priority_queue<Node*, vector<Node*>, Compare> pq;如何安全地从叶子节点回溯生成二进制编码字符串
不能在建树过程中边建边存编码——因为同一字符可能被多次压入/弹出，路径未定；必须等整棵树建完，再对每个叶子做 DFS 或 BFS 回溯。
立即学习“C++免费学习笔记（深入）”；
关键点在于：编码方向由父子关系决定，不是由插入顺序决定。左子树标 '0'，右子树标 '1'，这个规则必须统一且只在遍历时应用。
实操建议：
- 用
unordered_map<char string></char>存最终编码，避免重复计算 - 递归函数签名推荐为
void generateCodes(Node* root, string code, unordered_map<char string>& codes)</char> - 进入左子节点时传
code + "0"，右子节点时传code + "1"；只在root->left == nullptr && root->right == nullptr时才存入codes[root->ch] = code
贪心选择性质在 C++ 实现中如何被显式体现
哈夫曼算法的贪心性不体现在某一行代码里，而是整个循环结构的设计意图：每次取当前可用节点中频率最小的两个，合并成新节点并放回候选集——这个「局部最优合并」直接决定了全局最优编码长度。
容易被忽略的细节：
- 输入频率为 0 的字符必须过滤掉，否则会导致空节点参与合并，引发空指针解引用
- 只有一个字符时，
priority_queue只有一个元素，循环体（while (pq.size() > 1)）不会执行，需单独处理：编码强制设为"0"（不能留空） - 合并后的新节点
freq = left->freq + right->freq，但ch字段应置为占位符（如'\0'），避免误当有效字符输出
构建完成后如何验证编码是否满足前缀码与最优性
运行时无法自动证明最优性，但可以快速检查两个硬性条件：
- 所有编码互不为前缀：对任意两个不同字符
a、b，检查codes[a].find(codes[b]) == 0 || codes[b].find(codes[a]) == 0是否恒为 false - 加权路径长度（WPL）是否等于预期：手动算一遍
sum(freq[c] * codes[c].length())，和理论最小值比对（比如用动态规划算出的下界） - 更实用的调试技巧：打印整棵树结构（用缩进或括号表示层级），确认叶节点全是原始字符，内部节点
ch == '\0'，且无单子节点（哈夫曼树必为满二叉树）
真正难的是输入分布变化时的鲁棒性——比如频率含浮点数、超大整数、或来自流式输入。标准实现只接受 int 频率，扩展前先想清楚溢出和精度怎么处理。
