priority_queue默认为大顶堆，而哈夫曼树需每次取最小权值节点合并，必须用小顶堆；否则贪心失效，导致WPL增大。正确做法是使用greater或自定义比较器使权值小者优先。
为什么 priority_queue 默认不能直接用于哈夫曼树节点比较
因为 priority_queue 默认是大顶堆（最大堆），而哈夫曼构造要求每次取权值最小的两个节点合并——必须用小顶堆。若不自定义比较逻辑，top() 返回的是最大权值节点，贪心策略直接失效。
常见错误现象：priority_queue<node></node> 编译失败，或构造出的树编码长度明显偏长、WPL（带权路径长度）远高于理论最小值。
- 正确做法：传入自定义比较仿函数，或使用
greater<node></node>（前提是重载了operator>） - 推荐写法：
priority_queue<node vector>, greater<node>></node></node>，前提是Node重载了operator>，且语义为“权值越大优先级越低” - 更稳妥的写法是用 lambda 包装的函数对象（C++20 起支持），但注意
priority_queue的 Compare 类型必须是可默认构造的，lambda 通常不可默认构造，所以仍建议用结构体或重载运算符
如何设计 Node 结构并保证合并时权值与指针安全
哈夫曼节点既要存字符和权值，又要支持动态构建二叉树结构，因此必须含左右子指针；同时，叶子节点需标记原始字符，内部节点则无字符意义——这点容易被忽略，导致解码失败。
关键细节：
立即学习“C++免费学习笔记（深入）”；
- 叶子节点的
ch字段有效，内部节点的ch应设为特殊值（如'\0'或 -1），避免误判 - 权值必须是
int或size_t，不能用float——频率统计通常是整数计数，浮点会引入精度误差和比较不确定性 - 构造内部节点时，新节点权值 = 左右子节点权值之和，**不能**只取 max/min，这是贪心合并的本质
- 所有
new Node(...)分配的内存，应在外部统一delete（或改用智能指针），否则必泄漏；实际项目中建议用unique_ptr<node></node>管理
buildHuffmanTree 函数里合并循环的终止条件怎么写才不出错
标准哈夫曼算法要求：当队列中只剩一个节点时停止合并。但初学者常写成 while (pq.size() > 1)，这在输入只有一个字符时会跳过循环，返回空树——必须确保单字符情况也生成合法树（根即叶子）。
实操建议：
- 初始化时，每个字符建一个叶子
Node入队；即使只有 1 个字符，也要入队 - 循环条件严格用
while (pq.size() >= 2)，这样单节点不进循环，直接返回该节点即可 - 每次循环 pop 两个节点，new 一个父节点，左右子指针分别指向它们，再将父节点 push 回队列
- 注意 pop 顺序：先取的应为左子（不影响编码唯一性，但保持惯例利于调试）；实际编码时左右互换仅影响码字 0/1 分配，不影响最优性
从哈夫曼树生成编码字符串时递归遍历为什么容易栈溢出或重复访问
直接写深度递归遍历，在极端不平衡树（如全频次为 1 的 n 个字符）下，递归深度可达 O(n)，而 n 较大时（如 10⁵ 字符集）极易爆栈；另外若未标记访问状态，可能因指针误连形成环而无限递归。
更健壮的做法：
- 用显式栈（
stack<pair string>></pair>）替代递归，每层压入节点及其对应编码前缀 - 只对叶子节点收集结果：判断
node->left == nullptr && node->right == nullptr，此时node->ch才是有效字符 - 非叶子节点不记录编码，仅用于向下传递前缀（如左走加
'0'，右走加'1'） - 若输入含空字符（
'\0'）或控制字符，编码结果应存入map<char string></char>而非简单打印，避免终端截断
真正麻烦的不是构造树，而是字符频次预处理是否去重、零频字符是否过滤、相同频次节点合并顺序是否稳定——这些都会影响最终编码形态，但不影响最优性。实际应用中，只要 WPL 最小，就无需纠结具体 0/1 分布。
