最稳妥是用 priority_queue 配合自定义最小堆比较器、unique_ptr 管理内存、引用+回溯生成编码，并确保频次为整数且相等时有稳定排序。
为什么直接用 priority_queue 实现哈夫曼树构建最稳妥
因为哈夫曼算法本质是贪心：每次合并权值最小的两棵子树。C++ 标准库的 priority_queue 默认是最大堆，但我们需要最小堆来快速取最小频次节点——所以必须自定义比较器，否则会反复弹出最大值，结果完全错误。
常见错误现象：priority_queue 编译通过但编码长度全错，或生成的树高度异常；根本原因是没重载 operator 或比较逻辑反了。
- 用
priority_queue前提是, greater > Node重载了operator>，否则编译失败 - 更可靠写法是传入 lambda（C++11+）或独立仿函数，显式控制“小的优先”
- 节点结构里不要只存
freq，必须带标识信息（如char ch或bool is_leaf），否则重建编码时无法区分叶子/非叶节点
如何避免构建过程中内存泄漏和空指针解引用
哈夫曼树是动态建树过程：每轮 pop 两个节点，new 一个父节点，push 回队列。最终只剩一个根节点。若用裸指针且不统一管理，极易在中途异常或提前 return 时漏删。
使用场景：频次数据来自文件或网络流，可能中途读取失败；或需支持多次构建，不能依赖全局静态清理。
- 绝不直接用
new Node+ 手动delete—— 构建失败时难以保证所有中间节点都被释放 - 改用
unique_ptr，让父节点的left/right成员也声明为unique_ptr，所有权自动转移 - pop 出的两个节点直接 move 进新节点的左右子树，无需拷贝；最后根节点离开作用域时自动递归析构整棵树
- 若必须用裸指针（如嵌入式环境无智能指针），至少封装一个
HuffmanTree类，在析构函数中后序遍历 delete 全树
buildCodeMap() 递归生成编码时为什么容易栈溢出或编码颠倒
编码本质是根到叶子的路径：左走记 '0'，右走记 '1'。但递归参数若传的是字符串拼接（如 code + "0"），每次调用都复制一整段编码，深度大时开销爆炸；若用引用传参但忘记回溯，会导致所有叶子共享同一串乱码。
性能影响：对 256 个 ASCII 字符建树，平均深度约 8，但最差情况（如某字符频次极低）可达 20+ 层；字符串反复拷贝会让时间从 O(n) 退化到 O(n²)。
- 参数用
const string& prefix不解决问题——C++ 引用不能绑定临时对象，prefix + "0"仍是新字符串 - 正确做法：传
string& code引用，进入左子树前code.push_back('0')，返回前code.pop_back()；右子树同理 - 叶子节点触发时，把当前
code拷贝进 map（如codeMap[node->ch] = code），此时才真正存储一份 - 若担心递归深度，可改用栈模拟 DFS，但需额外存节点指针 + 当前编码字符串，空间未必更省
贪心正确性在 C++ 实现里哪些地方会被悄悄破坏
哈夫曼贪心成立的前提是：字符频率已知且固定、无其他约束（如最大码长限制）。但实际代码中，几个细节会隐式引入偏差。
容易被忽略的地方：输入频次为浮点数或归一化后的比例值；或多个字符频次相等时，priority_queue 的“相等元素顺序不确定”导致不同运行结果；或未处理频次为 0 的字符（应跳过，否则生成无效单节点子树）。
- 输入频次必须是整数（如字节计数），浮点频次会因精度误差导致排序错位，使小频次节点意外排在前面
- 当两个节点
freq相等时，比较器必须提供稳定次序（例如再比ch值或指针地址），否则多线程下或不同 STL 实现中树结构不一致 - 若所有字符频次都是 1（如去重后的字母表），哈夫曼树退化为平衡性很差的链状结构，但算法本身仍正确——只是此时定长编码反而更优，这点需由上层业务判断，不是算法能解决的
- 最终编码表必须覆盖全部输入字符，检查
codeMap.size() == original_char_count，缺项说明有频次为 0 的字符被漏处理或建树中途异常退出
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
