直接用 priority_queue 构建哈夫曼树时，若仅重载 operator
为什么直接用 priority_queue 构建哈夫曼树时，
operator 必须定义为“小顶堆”逻辑？因为哈夫曼算法每次需要取出频率最小的两个节点合并，
std::priority_queue默认是大顶堆，不重载就会拿错——你看到的“最小频次节点”其实是最大频次的那个。实操建议：
- 定义结构体
Node时，重载operator 返回a.freq > b.freq（注意是大于号），才能让priority_queue变成小顶堆- 别用
greater试图补救：它要求Node有operator>，反而更易出错- 调试时可临时加一行
cout 验证堆顶是否真为最小值构建编码表时，递归遍历生成
string编码为什么容易栈溢出或内存爆炸？不是递归本身有问题，而是频繁字符串拼接：
code + "0"每次都新建对象，在深度较大（如 20+ 层）的哈夫曼树中会触发大量临时string分配与销毁。实操建议：
- 改用引用传参 + 回溯：传入
string& code，进入左子树前code.push_back('0')，返回前code.pop_back()- 初始化
code时预留足够空间：code.reserve(256)，避免多次扩容- 叶子节点写入编码表后，立刻
return，别让递归继续向下
buildHuffmanTree返回Node*后，怎么安全释放整棵树内存？哈夫曼树不是二叉搜索树，没有 parent 指针，无法从叶子反推路径；若只存根节点指针，又没记录所有分配过的
new Node地址，delete时必然漏删或重复删。实操建议：
- 构建过程中用
vector记录所有nodes new出来的节点指针（包括中间合并节点）- 函数末尾把根节点也 push 进去（它也是 new 来的），最后统一遍历
delete- 千万别在构建循环里
delete左右子节点——它们已被新节点引用，删了就成悬垂指针字符频次统计阶段，
map和unordered_map选哪个？纯看输入规模：如果待编码文本只有几百字节（比如配置项、日志片段），两者没差别；但若处理 MB 级日志或 DNA 序列，
unordered_map平均 O(1) 插入能快 2–3 倍。实操建议：
- 用
unordered_map，但记得在循环前调用freq.reserve(256)——ASCII 字符最多 256 种，预分配桶避免 rehash- 别用
map试图“保持插入顺序”：哈夫曼不依赖字符顺序，且map的红黑树排序对后续 priority_queue 构建无任何帮助- 读文件统计时，用
istream::get()逐字节读，比getline+string更省内存哈夫曼树的“最优性”只在给定频次下成立，但实际压缩效果还取决于频次统计是否真实反映数据分布——比如对加密后的随机字节流硬套哈夫曼，编码长度反而可能变长。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
