直接用 priority_queue 实现哈夫曼树更可靠，因其避免手写最小堆的边界错误；需显式指定小根堆（如 std::greater），否则贪心失效；频次统计须强转 unsigned char 防越界；推荐 unique_ptr 管理内存；编码生成宜用迭代 DFS 防栈溢出。
为什么直接用 priority_queue 实现哈夫曼树构建更可靠
手写最小堆容易出边界错误，而 std::priority_queue 默认是大根堆，必须显式指定小根堆比较逻辑，否则编码长度全错。关键不是“能不能写”，而是“改一个参数就全崩”——比如漏写 std::greater 或传错模板参数顺序，会导致每次 top() 取到最大频次节点，贪心选择彻底失效。
实操建议：
- 声明必须写全：
priority_queue，不能省略, Compare> pq; vector -
Compare必须定义为函数对象（struct 重载operator()），不能用 lambda（C++11 起不支持作为模板参数） - 节点指针入队前确保
new成功，否则空指针解引用在top()后立刻崩溃
字符频次统计阶段最容易忽略的输入边界
很多实现直接用 string 遍历并 ++count[c]，但若输入含空格、换行、ASCII 扩展字符（如中文 GBK 编码字节），char 当作 unsigned char 处理时会越界访问 count[256] 数组——尤其在 macOS 或 Linux 下默认 char 是 signed，'\xFF' 变成 -1，导致数组负索引。
实操建议：
- 频次容器统一用
vector，统计时强转：count(256, 0) count[static_cast(c)]++ - 若需支持 Unicode（如 UTF-8 字符串），必须先做 UTF-8 解码，按 Unicode 码点而非字节统计——否则一个汉字被拆成 3 次计数
- 空输入或全相同字符（如 "aaaa"）要单独处理：此时哈夫曼树退化为单链，编码全为 '0'，不能假设一定有左右子树
buildHuffmanTree 中合并节点时的内存管理陷阱
每次合并两个最小节点生成新父节点，若用裸指针且忘记 delete 原节点，必然内存泄漏；但若过早 delete，后续 top() 返回的指针就悬空了。标准做法是只在最终遍历编码时释放，或全程用 unique_ptr。
实操建议：
- 推荐用
unique_ptr替代裸指针，声明队列为priority_queue, vector >, Compare> - 合并时直接
move：auto left = move(pq.top()); pq.pop();，避免拷贝和手动delete - 不要在循环中对
pq.top()做任何修改（如赋值left->parent = new_node），因为top()返回的是 const 引用，强行 cast 会触发未定义行为
生成编码字符串时递归 vs 迭代的取舍
递归写法简洁，但深度由树高决定，最坏情况（极度不平衡）可能栈溢出；迭代用栈模拟虽安全，但需额外存路径字符串或 bit 栈，易在拼接时多加 '0' 或漏位。
实操建议：
- 优先用迭代 DFS：每个栈元素存
pair，入栈右子树再左子树，保证左 '0' 右 '1' 顺序 - 若追求极致性能，改用位运算 + 整数存储编码：每合并一层左移 1 位再加 0/1，最后用
bitset转字符串，避免频繁+=字符串拷贝 - 叶子节点判断必须严格：
node->left == nullptr && node->right == nullptr，不能只判!node->left——内部节点也可能某子树为空（比如只有单字符输入）
真正难的不是写出能跑通的版本，而是让代码在输入含控制字符、空字符串、超长重复串、非 ASCII 字节流时依然输出合法编码——这些 case 往往卡在类型转换、容器索引、指针生命周期三个地方，调一次 valgrind 或开 ASan 很快暴露。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
